Iron Router, and client-side routes


#1

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?


#2

Bump - any info on this would be great!


#3

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.


#4

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


#5

@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


#6

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?


#7

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.


#8

That’s what I thought. Thanks, Nathan!


#9

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.


#10

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!


#11

Actually, here’s where documentation and code differ:

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

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


#12

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.