URLs and Routing

[stubailo]

Article outline

https://github.com/meteor/guide/blob/master/outlines/routing.md

Major decision points

1. Flow Router because it works well across Blaze and React, and is relatively simple
2. The URL/Router is not the main driver of the app - it's just another data source
3. Only "smart" components should read the route data (see more in the Blaze or UI articles)
4. Server side routing/HTTP API is not covered here

[stubailo]

This article currently assumes this issue will be solved: meteor/meteor#1602

[stubailo]

It's not clear if the loading indicator section belongs here - it's kind of a legacy thing from the Iron Router days that people expect loading to be tied to the router?

[stubailo]

@zimme your package is in here!

@arunoda this is using Flow Router, I wonder what you have to say or add about it.

[stubailo]

@banglashi I also mention flow router helpers in here.

[stubailo]

@deanius what is the status of okgrow:analytics with Flow Router? This guide assumes that it will just work.

[arunoda]

@stubailo let me go through this.

[robfallows]

@stubailo : re okgrow:analytics, we're using astronomerio for analytics routing. No idea if one is "better" than the other, but both seem to offer similar functionality.

[vladshcherbin]

@stubailo I think the routing guide is very long and has many unnecessary parts.

• Why did you choose long questions instead of slick Table of Contents?
• Do we really need to tell, what a url is and what it serves for? I thought the guide is not for complete novices..
• The parts, where it is shown, how to render the template. Or how to subscribe and highlight the active route. And then, permissions - they are also done on a template level. All this things were part of Iron Router, the Flow Router only handles urls. All the other stuff is done not on a Router level. And this is one of the main things that confuses people.

How about splitting this guide into Router and Templates/Views guides?

What do you think?

[stubailo]

Why did you choose long questions instead of slick Table of Contents?

The questions at the top are more meant to be a summary of the topic. See the Rails guide here: http://guides.rubyonrails.org/routing.html

There should be a table of contents automatically generated from the headings of the article, we just haven't built that yet. I agree it makes the whole thing a bit harder to understand, but that's the current state.

Do we really need to tell, what a url is and what it serves for?

The point of this section is to emphasize that routes serve a very different purpose in client-side rendered apps. In a server side app, you need a route for every single thing. In a client-side app, you only need routes for stuff that needs to be linkable. The rest can be done in JavaScript.

All the other stuff is done not on a Router level. And this is one of the main things that confuses people.

I think you're absolutely right. By mentioning these topics here, we're conceptually tying them to the router. Let's break it down:

Definitely router topics

• showing active route
• helpers for generating links
• displaying different templates for different routes (probably the main function of a router!)
• analytics
• redirecting to other routes when a URL has been moved

Are probably template/view structure topics

• showing nice messages when the user can't see data
• loading data

[stubailo]

@robfallows I feel like the OK Grow package is more relevant to most people since it supports a wide variety of analytics services. As far as I can see, Astonomer just supports... Astronomer?

[vladshcherbin]

@stubailo I think, we should cover at least this topics:

• intro
  • what the routing does and tell, that we suggest using flow-router. Add here the installation in one line.
• basic routing
  • show some examples of simple route actions
• route parameters
  • show, how to accept route params, have optional ones, etc
• named routes
  • dedicate a chapter as it simplifies routing, linking and is a preferred way to build links
• route groups
  • show the examples with route groups
• triggers
  • show some examples with triggers
• displaying views
  • tell, that there are different engines and the examples are similar. show the example with blaze (blaze-layouts package) (without showing templates part) and add a link to the views/templates guide to read all about it. There, we can tell, how to build links, highlight them, manage permissions, etc.
• redirects
  • show, how to handle redirects
• 404
  • show, how to handle 404
• advanced complex examples
  • complex examples, like multiple languages, etc

So, this will show that we have a powerful router, although not in the core.

I also remember, why the template helpers for links are not in the core of flow-router - @arunoda told us, they are not the router part. I fully agree now ;)

Analytics is a tricky one, if you want to use for example google analytics and to send the page title there - you will need to do it on a template level too, since you subscribe and fetch the title after receiving.

[stubailo]

@vladshcherbin the outline you just proposed, as far as I understand, is a guide about how to use Flow Router's API. I'm trying to build something which talks about different URL-related use cases, and happens to use Flow Router as an implementation. I think almost any reasonable person would expect to learn about how to create links in this article, even if it's not actually "part of the router".