Best pattern for Flow Router use?

1

Hi,

Just say I have a route like
mythings/:thingID

Clicking on hrefs with different thingIDs doesn’t affect any template level subscriptions.

As FlowRouter recommends using template level subs and is removing router level subs in v3 what’s the most elegant way to update subscriptions when thingID changes in the route?

2

There’s a helper for FlowRouter.watchPathChange() that is reactive and can be used in reactive blocks. I generally use peerlibrary:blaze-components, so it might look like this.

Also, FlowRouter.getParam is reactive

import {BlazeComponent} from 'meteor/peerlibrary:blaze-components';

export class MyThings extends BlazeComponent {
  onCreated() {
    this.autorun(() => {
      FlowRouter.watchPathChange();   // reactive variable.
      this.subscribe('my_things', FlowRouter.getParam('thingID'))
    });
  }
}
MyThings.register('mythings');

I’m not necessarily sure if this is the correct pattern, but it does work

1 Like
3

Well, it’s a pattern recommended by the docs, so it’s a correct one.

Speaking of the docs @sirganya, I highly recommend to read them, you’ll learn more than just from tutorials.

4

Thanks for the first answer.

Kadira are not the MDG so their (excellent) packages are designed for their own needs. (that’s a quote from Arunoda) I personally don’t agree with some of their ideas, which I hope is OK, and they move away from some of the things I like about Meteor.

My question was designed to see if I was missing something more elegant than setting up a reactive binding to something that is designed to be non-reactive. That seems like an extra step and I wanted to see if that step could be eliminated. App state is difficult, IMHO routers should take care of state. Watching routes to decide state seems wrong, routers should decide state, components should do what they’re told. In this case my component is now dependent on watching a routers state. To me that makes it more fragile. I’m sure there are excellent reasons for the decisions made in designing FlowRouter. It’s even in the name. I was asking around to see if I’d missed something.

5

I don’t understand this part. If you are doing all of your subscriptions in templates as recommended, this won’t ever come up.

If you have a global page subscription, the recommendation is to do it in the layout template:

1 Like
6

In my case I have a subscription that takes a parent parameter and returns anything that is its child.

So I’d have a route like
mythings/:parent

The subscription is dependent on the :parent value and if that changes the list of items changes. Each item contains a link to view it’s children as each item can be a parent. The link is the mythings/:parent format with the :parent key being the _id of the item holding the link. It’s a tree with every item having the possibility of being a root. The href triggers a URL changes. When the sub was managed by the router this worked as I had been used to from previous router paradigms (ui-router in particular) but moving it to the template meant I had to watch the route and update the sub. I was curious to see how people were approaching this.

7

When I came to Meteor, one of the first features that felt weird was that Iron Router manages data at the router level. It just doesn’t work this way in other routers - be it Symfony, Laravel, Rails, Django, Ember, Angular or now React and Angular 2, so it was an alien concept. Routers may have provided some initial validation for parameters, but not the data.

Luckily Flow Router was already a thing so I didn’t have to enter that field.

8

The this.autorun block in a Template[templateName].onCreated updates whenever a reactive variable changes

FlowRouter.getParam is a reactive data source, therefore, whenever you change your parameters, it will also change your subscriptions.

1 Like
9

@corvid, that makes sense to me. Thanks.
@brajt I had been dealing with it a router level with ui-router. But now I have seen the light.
Thanks for all the input, amazing forum.

10

I’ve been more used to ng-router, so I’ll ask out of curiosity. Wasn’t $stateRouter’s purpose to manage only the place in the nested views in which the user is at the moment (for example, a particular place in tabs or acordeon, not the actual data? How does it look like in the new Angular2 router?

Sorry for the off topic.

11

The project I took over needed data to be loaded before views could be
rendered without serious refactoring so I was using resolve to preload
the data. When I used iron router it seemed like it was a similar vibe and
’resolve’ is pretty much the same as ‘subscriptions’ in FlowRouter I
think. Haven’t been forced to use Angular2 by an employer yet :wink: Been
focused on Meteor for the last few months.

1 Like