Need help getting started about iron-router

[cmather]

Hi Torsten85, We'll get a readme up as soon as we can. It's still a closed project as the code is in flux and not a lot of time to get people up to speed at the moment. So the plan is to get all the tests done, finish a readme, add an example, bang away at it on eventedmind, then open source it. If you have time to contribute that would be awesome.

[cmather]

In case its helpful to get you running quickly here are some quick points:

• Make sure you checkout the dev branch
• You'll probably put this router project in some directory and then reference that packages directory using the PACKAGE_DIRS environment variable - this will make it visible to meteor since this package isn't released on mrt yet.
• Once you clone the project into your packages directory, checkout the dev branch. You can then add the iron-router to a project using meteor add iron-router. When you fire up your project you should see a console error saying the route '/' is not defined.

Typical app.js file would look like this:

Router.map(function () {
  this.route('home', { path: '/' });
});

[Torsten85]

Thanks for your answer. Already tried that and making the Router available in my meteor project is no problem. But getting it to work is. I'm not receiving any error without configuring the routes. And the {{yield}} helper always returns an empty template. I guess I'm missing something fundamental here.

[cmather]

Can you confirm you're on the dev branch? If so, can you push your sample project to github so I can determine if there's a bug in the router? Thanks.

[mizzao]

I am trying to switch from Tom's router to this one and I am also not getting any bug without any route definitions. Additionally, Router.map is showing nothing after I used it to create the same routes as before.

Is Router.map client only or both?

[cmather]

@mizzao, oh that's a good point. I removed the Router exports on server side because of issues with the new linker code. I'm going to add it back once I get through the next set of changes. To confirm this is the problem you're having:

1. In your server console, do you see an Error saying something like "Router not defined"?
2. If you put your Router.map inside a Meteor.isClient block does the problem go away?

If it turns out to be something else, a github repo that I can look at would be helpful. But I know the server side stuff isn't there at the moment so that's probably the issue.

[mizzao]

I'm only using Router.map in a client file, so there's no error in the server.

Here's my repo and the file (https://github.com/mizzao/CrowdMapper/blob/master/client/index.coffee) that's defining the initial routes. Right now nothing is rendering, even the body. Tom's router worked fine before.

There are no errors in the client or server console. What helpers do I put in templates to put the router to use? For example, {{renderPage}} is what was used before.

[cmather]

You don't need to do anything special. No renderPage is required unless you want to render into a specific div. You also don't need to define any link click handlers as that's all taken care of. Let me take a quick look at your repo to see if I can spot something right away.

[cmather]

Git rid of the page-js-ie-support package for now. Also, can you tell me whether Router is defined in the javascript console? See if this is a timing issue or something else. Also, let me know what commit meteor-iron-router is currently at.

[cmather]

@Torsten85, @mizzao - Let me know if you were able to make some progress. My apologies for the difficulty in getting up and running. Once I get through this next release of my site I'll focus more time to making this project easier to contribute to. In the mean time, interested to know if there's a bug, or maybe another conflicting package that is causing you problems. If you're switching from another router like mini-pages or router, I would remove those and the dependencies (e.g. page-js, page-js-ie-support) from your project. This is a completely new and unrelated project and those dependencies aren't needed anymore.

Note- IE<10 has not been completed yet. But the page-js-ie-support won't help with that at the moment. It's a matter of integrating history.js, or parsing hash fragments and recognizing whether the browser supports pushState or not.

[mizzao]

Hi @cmather,

No worries at all! I am itching to see this router in public use (the layouts support something that is not possible in any of the other approaches right now) and I'm happy to be your guinea pig.

I've removed the other router as well as page-js-ie-support. Router is defined in the console on the client:

> Router
RouterUtils.extend.constructor {options: Object, routes: Array[4], _current: null, _deps: Deps.Dependency, _partials: YieldPartialDict…}

I am on the following commit - latest one on dev:

commit aeef1d6ebf393025aae6f166fb00a28802950659
Author: Chris Mather <[email protected]>
Date:   Thu Jul 25 00:40:54 2013 -0700

    Don't schedule a createFlush more than once.

the body is just empty right now. I'm just expecting something to show up at either / or one of the other paths, even if it's not the same as what I had before.

[cmather]

Hmm maybe this is a coffee script issue. I'll clone your repo and see if I can reproduce.

[cmather]

This might be a bug I introduced with the latest delayed inheritance that impacts a code path I haven't written tests for yet. I'm working on getting to the bottom of it now.

I wasn't able to get your project started - lot of other errors probably related to dependencies (even after running the setup.sh script) but I am able to reproduce nothing showing up in the body with a sample coffeescript app.

[cmather]

Okay sorry guys, this was a blatant bug I introduced in my late night sketch of flushing inheritance last night. It's been fixed on dev. BTW the process for testing and releasing will become more diligent shortly; sorry for the inconvenience in the mean time.

I also posted a simple coffeescript example which might show you some of the basic features: https://github.com/cmather/iron-router-coffeescript-example

[Torsten85]

@cmather @mizzao thanks for addressing this topic and getting to the bottom of this. I'll try the new commit today.

[mizzao]

Thanks @cmather for fixing this, works great now; and also providing the example - very helpful. I'll use that to contribute to the README.

Do you guys replace <body> templates completely, so that they don't get rendered anywhere?

[mizzao]

Hi @cmather, two questions:

1. How do we actually tell the Router to use a particular controller? I assume each controller is associated with a given layout.
2. How do we specify multiple layouts? I thought I saw this in your screencast and in my opinion it is pretty important, but from the code it's not clear that it's possible. For example, if we want to define a normal layout with /foo, /bar as well as /admin/task1 and /admin/task2 where the main site and the admin interface would use different layouts.

[cmather]

@mizzao,

For the body question, you can remove the body tag entirely if you want. I'm pretty sure Meteor will insert it back in. I don't use it at all in my application. @tmeasday has a different use case so he might be rendering the router manually. You can see the code for autoRender in: https://github.com/EventedMind/meteor-iron-router/blob/dev/lib/client/client_router.js line 308.

The logic for which controller to use can be found here: https://github.com/EventedMind/meteor-iron-router/blob/dev/lib/client/route_controller.js line 1150. The 4 cases are commented. Here is an example:

Router.map(function () {
  this.route('home'); // creates a route at path `/home` and creates an anonymous controller at route run time, calling the controller's `run` method. See https://github.com/EventedMind/meteor-iron-router/blob/dev/lib/client/route_controller.js for default implementation.

  this.route('posts'); // Because a PostsController is defined on the global object the router finds it automatically and instantiates it when this route is run. The default method to call on the PostsController is `run()` which just renders the controller's template by default.

  this.route('postEdit', {
    path: '/posts/edit',
    controller: 'PostController', // Use the PostController (value is a string so its evaluated at route run time
    action: 'edit' // specify a different method to run on the controller instance
});

PostsController = RouteController.extend({
  edit: function () {
    var params = this.params; // play with this in the js console to see how params work. Also documented in https://github.com/EventedMind/meteor-iron-router/blob/dev/lib/route_path.js.

    this.render('templateName', {/* render options which default to controller properties */ });

    this.render('aside', { to: 'aside' }); // you can call render as many times as you want to different yield regions
  }
});

For the layouts question, see the contentFor issue for details on the design decision. But in short, splitting a template up at runtime into essentially two different templates, and then creating an enclosing liverange posed a couple of problems related to reactivity. We decided it was best to not go against the template grain, and instead change the design to allow rendering one or more templates at runtime into a given named yield. If you don't specify a named yield it renders into the __main__ yield which is just {{yield}} vs {{yield 'name'}}

Hope this helps. I'll try to create a wiki page walking through the different code files this weekend.

[mizzao]

This is what I've figured out so far. I know it is not correct though.

I can't exactly tell what the controller should be associated with because the code definition for it has many possibilities. Is it attached to a layout? to a route? to the router as a whole? My code as is will only render the same home template for all paths, which seems to be what it's supposed to do. However, how do I change it to get the pages to work properly?

What if the four pages all have the same layout and I don't want to specify the named yields repeatedly?

Router.map ->
  @route('home', {path: '/'})
  @route('map')
  @route('events')
  @route('docs')

class @MapperController extends RouteController
  template: 'home'

  renderTemplates:
    'datastream':
      to: 'datastream'
    'sidebar':
      to: 'sidebar'

Router.configure
  layout: 'layout'
  controller: 'MapperController'

Your message came up as I was typing this. I'm reading it now.

[cmather]

I just read your layout/controller question more carefully. Let me add a little extra context for the relationships amongst the components.

Router: Controls the dispatch and run process, re-running the dispatch process any time the url location changes. Also responsible for rendering the layout, defined as an option on the Router. By default it will use a simple layout that is included with the package. It just has {{yield}} in it.

Route: Container class for storing route options and proxying path methods to the RoutePath. That's where the compiled path is.

RouteController: This is what gets instantiated when a route is actually run. By default there is a run method on the RouteController that gets called at route run time. It just calls this.render(); which renders the controller's template, defined either as an option or on the instance itself.

As a general design choice, options override instance properties. And options flow from the Router to the Route to the RouteController. So if you define an option using Router.configure({...}) all routes and RouteController's will see these options. If you define an option at route definition time: this.map('routeName', { options } the route will pass these along to the controller instance. As your app gets bigger you can just defined the templates and options on the controller's themselves.

A key design change in this version is that controllers are no longer responsible for layouts. See above.