You can check out Ryans Swapp’s screencast on using Meteor with Flowrouter and React: https://www.youtube.com/watch?v=kVbVBp35keQ
1 Like
Ah sorry, I should have stated that. You said you were struggling to get ReactRouter working with Meteor and React. So I thought this video was the best way to get you started.
ah my bad
1 Like
Does this example work with meteor 1.3?
Can you share an example of how you use both?
SSR is not only about SEO. Pre rendered html will show up much faster than a cleint side rendered app. Its great outlined here :
https://donejs.com (scroll to : Better Performance)
This is true. However, if your HTML/CSS shows up much faster than your JavaScript (say 1+ seconds) then you have a new problem. Now the user can click on buttons that won’t do anything but frustrate the user.
IMHO keeping the initial JS payload down (even code splitting in large apps) and not serverside rendering markup is the best tradeoff for small/solo dev teams. The amount of engineering and extra CPU cycles needed for good SSR is very expensive.
You’ve probably seen this but figured I’d share for others. According to Ryan Florence, SSR with React is actually pretty slow. Interesting tweet thread https://twitter.com/ryanflorence/status/708361005441507328
1 Like
SSR is an art. It cost CPU a lot and it adds data fetching latency as well. So, you should focus on getting the smallest possible data in the server.
You can simply use React No SSR to stop rendering some of your components in SSR.
3 Likes
yeah maybe both, initial ssr and payload down 
1 Like
Seeing that FlowRouter and Picker are abandoned with many PRs left un-merged, I decided to “restart” both.
Please see: FineRouter and FinePicker. Please submit PRs and ask for contributor roles to get more involved.
2 Likes
Just my 2 cents - I wouldn’t fork and maintain Picker. It is like a 3 line change to use Express to handle server routes. In addition, replacing existing code with Express requires renaming Picker and removing a parameter or two from route definitions. Dead simple. IMO it doesn’t make any sense for Picker to exist anymore.
@ryanswapp could you please elaborate, on installing Express on top of Meteor to handle server side routing?
Somewhere in server code:
import express from 'express';
import bodyParser from 'body-parser';
const app = express();
app.use(bodyParser.json());
app.get('some-route', Meteor.bindEnvironment(function(req, res) {
// Do route stuff
}));
WebApp.connectHandlers.use(Meteor.bindEnvironment(app));
That’s all you have to do to get Express working.
5 Likes
I’m already using Picker, and don’t have time to run down how to use Express. Just made sense to break Picker off into FinePicker for me (took no time really). But this way, there’s no barrier to contributions.
I was previously on picker with a fair number of server side routes and it took me about 10 minutes to convert to Express (I’m not all that familiar with Express). Literally, all you have to do aside from the code above is change this:
Picker.route('/post/:_id', function(params, req, res, next) {
var post = Posts.findOne(params._id);
res.end(post.content);
});
To this:
app.get('/post/:_id', Meteor.bindEnvironment(function(req, res) {
var post = Posts.findOne(req.params._id);
res.end(post.content);
}));
If the routes you have use route parameters you simply need to add ‘req.’ to the front of your code:
// Picker
params._id
// Express
req.params._id
I think aside from that it’s identical to picker code (Arunoda clearly was copying Express’s API). Just food for thought if you want to get rid of a meteor dependency and move to a more NPM centric approach (which is the smart route since Meteor’s package system is likely to be gone once they make the jump to npm modules).
1 Like
Thanks for going out of your way to provide clear examples with code @ryanswapp, it’s appreciated. Thanks to you I’ll try to convert one of my routes over as a test.
1 Like
I’m not entirely sure if Express and Picker can co-exist in the same app… If converting just one route works let me know!