Iron Router, and client-side routes

captsaltyjack · May 13, 2015, 6:58pm

I’ve seen many projects that have routes defined in /lib/routes.js, and some that decide to have it client-side only, in /client/routes.js. What exactly is the difference? What is a client-side route and what’s the advantage of doing it that way?

captsaltyjack · May 15, 2015, 5:57pm

Bump - any info on this would be great!

copleykj · May 15, 2015, 6:43pm

I think for some it’s a matter of the fact that it works in shared space so they don’t bother segregating them to the client, for others though that are using something like fast-render, having the route defined in shared space allows fast-render to run your subscriptions and then send down the data to the client with the first page load. This for me is a huge advantage and I use it this way because of that.

captsaltyjack · May 15, 2015, 11:47pm

Ok, but if I have routes.js in the clients folder rather than lib, what effect does this have on my app? If any?

nathan_muir · May 16, 2015, 1:54am

@captsaltyjack - With the current versions of iron:router you need to define your routes in a “shared” location.

The reason is when someone goes to “https://myapp.meteor.com/some/deep/route” - if /some/deep/route isn’t defined on the server, it will respond with a 404.

Here’s the relevant section of the guide: https://github.com/iron-meteor/iron-router/blob/devel/Guide.md#404s-and-client-vs-server-routes

captsaltyjack · May 16, 2015, 2:49am

Interesting.

you need to define your routes in a “shared” location

So people who are using iron:router client-side only are doing it wrong?

nathan_muir · May 16, 2015, 4:56am

Yep, iron:router needs to be aware of all routes on both the client and server.

The router is aware of all the routes on the client and the server. This means you can click a link that takes you to a server route, or it might take you to a client route. It also means that on the server, if there is no client route defined, we can send a 404 response to the client instead of loading up the Meteor application.

That being said… routes will work if they’re only defined on the client… you just can’t link directly to them.

captsaltyjack · May 18, 2015, 6:28pm

That’s what I thought. Thanks, Nathan!

seeekr · May 18, 2015, 7:33pm

I can not confirm that. I have an app where I have all my routes in client/ and I can link to and open any route/URL no problem. There’s not even any technical reason for it to be that way since the server can just easily send the app for any route without anything special, if it doesn’t find any specific server-side route, and then the client side router can figure out if it has a route defined for that or not.
I do have meterhacks:fast-render enabled, though, but I’m configuring it manually since it didn’t play nicely with defining controllers along with the routes on the server side. Not sure how others are going about that, but that definitely didn’t work for me.

seeekr · May 18, 2015, 7:35pm

Maybe you can speak real quick about whether you do define custom controllers for your routes and if so, did you have to do anything special for your configuration to just work? Because as I said above, for me Meteor then was just complaining about controller classes (I think the iron:router base controller class) not being available on the server. Thanks!

nathan_muir · May 18, 2015, 11:12pm

Actually, here’s where documentation and code differ:

github.com

iron-meteor/iron-router/blob/9c369499c98af9fd12ef9e68338dee3b1b1276aa/lib/router_server.js#L81




// if there are no client or server handlers for this dispatch
// then send a 404.
// XXX we need a solution here for 404s on bad routes.
//     one solution might be to provide a custom 404 page in the public
//     folder. But we need a proper way to handle 404s for search engines.
// XXX might be a PR to Meteor to use an existing status code if it's set
if (!controller.isHandled() && !controller.willBeHandledOnClient()) {
  return done();
  /*
  res.statusCode = 404;
  res.setHeader('Content-Type', 'text/html');
  msg = req.method + ' ' + req.originalUrl + ' not found.';
  console.error(msg);
  if (req.method == 'HEAD')
    return res.end();
  res.end(msg + '\n');
  return;
  */
}

It appears the code in iron:router that returns 404's has been commented out…

I guess this means there’s no current reason to define routes on both client and server… but it might happen eventually…

cooperm · July 1, 2015, 11:17pm

I’ve been wondering about this, too. But I do know one good reason for putting it in /client which is why I believe a lot of people are doing it this way:

If you use iron:router enough (and put routes in shared space) you’ll eventually run into issues and bugs due to putting in code that either works only on the client or server, which leaves you with having to define the same route twice (inside Meteor.isClient/Server statements) or having those conditionals inside your route definitions which can sometimes get confusing or make your code harder to read. Regardless of whether it’s in /client or shared space it will be linkable, and you’ll notice that almost all the code in your routers that only run on the client or the server will usually be client-side code. Therefore you put it in client, separating them from server-side routes which usually serve logically different purposes (like APIs), and improves organization since you can put your template/view files next to their respective router/controller.