Some design considerations about iron-router

[cmather]

@Torsten85, Thanks for these ideas. Seeing some of your code would be great, just include a link here. I think we'll lock this version down and release it soon, as I talked about releasing it almost a month ago :-). But we can start a sketch pad for the next milestone. Maybe I'll add an Issue Type called Idea.

[mizzao]

I like the design of the router and the rather natural hierarchy for configuring it. But, for a meteor-specific router, some things bother me a little bit:

• Having a single layout, but re-rendering all yields for each route, seems a little weird. I know we had some of this discussion, but I think not re-rendering identical yields actually makes more sense. For example, a common use for the old router was to have a dynamic page under some top or side navbar. Rendering the navbar in a yield would cause all JS effects on it to be lost, and require everything to be moved to the Session. If you think about the reactive nature of Meteor, where templates are not re-rendered unless their content actually changes, it's kind of weird to have so much re-rendering when routes change. It will actually be noticeable if there is a lot of data involved.
• At the same time, with going to all this trouble to support layouts, it seems strange not to support multiple layouts. Otherwise, things are not much different from using Tom's router with some session variables that control different sections of a layout template.
• Tying into both of the above, I think a real benefit of a Meteor-aware router is the ability of smart packages to interact with the routes. This could mean anything from adding additional routes with their own templates on to the page, or defining route and controller components that can be reused. For example, I think that something like http://observatoryjs.com/ could just add a route /observatory when you include it in your app, from which you can monitor the app internals and do various other things. I was hoping that the router would be modular enough that I could use it to add a backend admin interface to a meteor app which already had routes, which is impossible in the current design.

[cmather]

@mizzao, Thanks for the ideas. I agree with some of that, namely that allowing you to specify a different layout on the controller is a good idea, albeit with a different architecture than what we had before. Previously, the controller actually was in charge of the bulk rendering, and we rendered by rendering the child template into the layout, effectively composing two templates into one. This was problematic for the reasons you can read in the contentFor issue discussion. But that doesn't mean we can't allow for dynamic layouts, it just changes where we put it and how it works. We also were running into time constraints so decided to simplify quite a bit and get something useful out there, and then we can iterate on the next version. Specific comments to your thoughts above:

• The question is, is there actually that much re-rendering. Yes, there is re-rendering on a route change. But if you had truly static parts of your site, you could render the router into a specific area of the page. Named yields are built for reactive templates, where we think it's likely the content in that part of the layout would change (keep in mind the layout itself is not re-rendering, just its named yield areas). I think the more interesting use case is where you want to keep a layout basically the same (say, with no named yields.. just a main yield {{yield}} but you want an entirely different layout for a particular page (like your admin example).
• Agreed that supporting multiple layouts is a good use case. In terms of differences between this and Tom's Router, or mini-pages, there are many differences - layouts being just one of them.

1. Compiled paths with ability to go from path to params, and params to path giving way for path helpers; with support for wildcard parameters, regular expressions, named wildcard parameters
2. controllers and controller actions
3. waitOn and wait (to wait on one or more subscriptions - all built into the rendering process, a data object/function that can be used in tandem with a not found template and the wait process
4. auto rendering into body or manual rendering into a specific location (with one or more routers if you'd like)
5. reactive Location for reactively dealing with url change events and separating it from the router; providing access to Location directly in your app if you want to use it
6. Optionally run a route reactively (sometimes you don't want the route to be reactive)
7. Properly tearing down the previous route's computation before starting a new computation (turned out to be sort of tricky)
8. before and after filters that can cascade as options from the router to the route to the controller
9. onBeforeRun/onAfterRun hooks that are only called once for the first time the controller is run
10. onBeforeRerun/onAfterRerun hooks that are called on reactive re-runs of the controller
11. There's a lot of other changes, but these are the ones I can think of off the top of my head

• I think this is a good use case. If we add the ability for a controller to specify a layout, but instead of composing two templates together, let the router handle the layout, I think this could work well. Just need to design the new mechanism. Something like, if the controller has a layout defined, the router will render that new layout if it hasn't been rendered already. Couple of design snags like what to do about the data context, where are the event handlers, etc. defined.
• In summary, I think we should definitely be thinking about how to make the layouts part better. Just need to figure out when to release a version so people can start playing. Maybe 0.1 is only one layout, with named yields. 0.2 is routes can change the layout.

[tmeasday]

@mizzao -- I'm interested by your last point. In what way is it difficult for a package to integrate with IR?

[cmather]

Whoops, meant to throw this in the idea ice box milestone, not close it.

[ai10]

This may be a whole different design perspective ...
but might it be reasonable to use what might be called 'generic' Templates

  <template name="genericLayout">
     {{> genericNavbar}}
     {{> generic Content}}
 </template>
 <template name="genericNavbar">
 ...
 </template>
 <template name="genericContent">
 ....
 </template>

etc inside the page

{{> genericLayout}}

And instead of using a handlebar helpers to inject html into a template, perhaps use the router to rewrite / redefine the generic templates per a specific template for a route

 this.route('specificAction', {
   path: '/specificAction/:action'
   layout: "specificLayout"
   body: function (action) {
     return "specific"+action+"Content"
   }

when router.run()

delete Template.genericLayout

Template.genericLayout = Template[this.layout]
Template.genericContent = Template[this.body]

unspecified parameters would lead to

 'genericNavbar' being overridden with 'defaultNavbar'

[cmather]

Passing the parameters to the action method is probably a good idea. Take a look at the latest changes on the dev branch (History.md).

On automatically creating routes, I'm not sure on this one. Right now, the route automatically looks for a RouteController in the global namespace if it can find one, when the route is run. But if you create a new RouteController it doesn't automatically create a new route.

My instinct is that this would be confusing to people, but my background is not in php frameworks so maybe I'm missing something.

Keeping this open for now. Will circle back.