Blog Post: Rethinking Subscription Management in Meteor (Flow Router & Template Level Subs)

announce
1

We got Meteor 1.0.4 now and it has template level subscriptions.

So, now we are looking for some patterns to use Template levels subscriptions with Meteor. And we have some discussion whether to route level subscriptions or template level subscriptions.

To me, both are useful. But, when using route level subscriptions, we should avoid techniques like waitOn. Flow Router has better way(I think) of managing subscriptions in the router.

So, have a look at my blog post and you can decide which subscription management techniques suits for your app.

Let me know, what do you think about it.

6 Likes
2

One aspect of iron-router that you made no reference to at all was itā€™s ability to set the data context for a given route. When using iron router in the past Iā€™ve found this to be quite useful.

Obviously, flow architecture is a complete rethink for most of us, so how would you envision data context being set in a flow application? Template helpers? Or at the component level?

1 Like
3

Data context is an anti pattern to me. You should never try to set data in the route level. It should be handled in the template layer.

Since IRā€™s data context is reactive, when using it with templates, youā€™ll have to face re-rendering issues and possibly re-run router a lot.

4

The chapter ā€œrouter.current() is evilā€ is even more true for data(), because this function potentially triggers a large amount of re-rendering with no explicit action from the programmer.

autorun is delicate to use , and I think it should never be hidden from the programmer. One big issue about IR is that it heavily relies on hidden autorun.

5

So as an example, say you have a route which shows a list of all blog posts on the left hand side, and when one is selected it should show that blog post on the right, but the route url doesnā€™t update to reflect this (contrived, I know).

Previously I might have passed the blog post id into the template like: {{>blogPost selectedBlogId}}

How would you recommend doing it? Use a session variable and just let the blogPost update reactively when it changes? Feel free to give an example that makes use of other ā€œflowā€ modules!

6

If you are not changing route when the item clicked. So, router canā€™t do anything. Router shouldnā€™t do anything.

Iā€™m not sure. You can use a session. May be with a reactive variable assigned to the template state.

7

Fair pointā€¦ So assuming that the route was: /blogs/:blogId where :blogId is optional, how would you do that with flow-layout and flow-router, without re-rendering the entire view?

8

You can get the blogId with `FlowRouter.getParams(ā€˜blogIdā€™) from inside templates. Then do what you want.

So, if there is no param for blogId, you can render anything you need. (may be a list of posts). If thereā€™s a blogId, just render the post.

Hereā€™s the thing. You try to think by looking at the view of IR (assuming router does the rendering). Try to think in the Meteor way with templates. Router is just a single part of the app.

Anyway, Iā€™m not saying IR is not a bad solution at all. May be we could make it better by introducing some of our APIs.

9

@arunoda Can you give an example where Iron Router could rerender without control ?