#contentFor and flow-router


I am planning to transition my app from iron:router to flow-router (or more accurately to ostrio:flow-router-extra) and was heavily using the {{#contentFor region}} ... {{/contentFor}} helper from Iron:Router.

I wonder what the best practice/pattern for this would be in Flow Router? Should the route definition submit data for the different regions? That would mean all the logic embedded in a template would have to be ripped out and put into the route definition.

Any suggestions welcome.


I haven’t used Iron Router, but looking at the docs it looks like it’s just a helper around Template.dynamic

So the equivalent in flow-router should be something like:

<template name="fooLayout">
  {{> Template.dynamic template=header }}
  {{> Template.dynamic template=main }}
  {{> Template.dynamic template=aside }}
  {{> Template.dynamic template=footer }}
import { FlowRouter } from 'meteor/ostrio:flow-router-extra';
import { BlazeLayout } from 'meteor/kadira:blaze-layout';

FlowRouter.route('/bar', {
  action() {
    BlazeLayout.render('fooLayout', { 
      header: 'header',
      main: 'postList',
      aside: 'postMenu',
      footer: 'footer'

Passing the region as data to Template.dynamic instead of as argument to contentFor


That’s what I have come up with, but it does NOT mirror what was possible with Iron:Router.

You could have yields with specific regions in your layout template and then add content to the different regions by including content in other templates, thus embedding logic inside your template, which now has to be put into the route.

<template name="layout">
 <nav>{{>yield "navbar"}}</nav>
 <div class="content"> {{>yield}} </div>
 <section class="footer">{{>yield "footer"}}</section>

<template name="hello">
 This is stuff that goes in the main part
 {{#contentFor "footer"}}


Ahh okay then, I misread the iron-router docs. That does look like a handy way to map content to a location like that.

Sounds like if you want to do that with flow-router you’ll need to build your own abstraction to achieve it


Yes this is something you loose going form Iron-router (did so 18 months ago with a project). Flow router is more simplistic (and therefore you eliminate troublesome ‘overreactivity’ sometimes created by IR), which is why everyone switched to it. Basically you just handle all data reactivity/subscriptions etc. in the templates.