[How to] Setup Meteor-1.3beta + React + React-router via NPM

How to setup Meteor-1.3beta + React + React-router via NPM:
Special thanks to ciwolsey on freenode/#meteor whose instructions I’m sharing below.
Feel free to reply with corrections/improvements.

1) Ensure Meteor-1.2 and node.js are both installed.

2) Create a new meteor-1.2 project. For example, my project is named helloworld.
$ meteor create helloworld

3) Enter your new project’s directory:
$ cd ~/helloworld

4) Update the new project to Meteor-1.3beta (official instructions here)
$ meteor update --release 1.3-beta.12

5) Enable module support introduced in the Meteor-1.3beta.
$ meteor add modules

6) Initialize npm to generate your dependency list (package.json):
$ npm init
*****note: you may accept all the default values requested --none of the options matter.

7) Install react, react-router and dependencies via npm:
$ npm install history react react-dom react-router --save

*****note-1: You can view all available version of a package via “npm view versions”.
*****note-2: At the end of the installation, npm may warn you about missing dependencies. For example, I was originally told that “…react-router@1.0.3 requires a peer of history@^1.1.70…”. To correct this, I simply installed history.
*****note-2: You can also ignore warnings like: “npm WARN EPACKAGEJSON helloworld@1.0.0. No repository field.” These are just because you didn’t enter every requested detail during ‘npm init’.

8) Delete the three .html, .css and .js files located inside ~/helloworld/.
Within ~/helloworld/ you should now only have the following:
~/helloworld/.meteor & ~/helloworld/node_modules & ~/helloworld/package.json

9) Create a ‘client’ folder inside ~/helloworld/ that contains main.html and main.jsx:
~\helloworld\client\main.html & ~\helloworld\client\main.jsx

10) Edit main.html and main.jsx as follows:

11) Start the app.
$ meteor

Check your browser’s console for any errors then head to where you should see ‘Hello World’ printed --Meteor_1.3, React and React-Router are now setup!

Be sure to checkout the What is the recommended folder structure for Meteor 1.3? thread


I’d suggest also meteor add react-meteor-data and then using the ReactMeteorData mixin!


I’m saying something a bit different - you can use react-meteor-data with React from NPM.


or try out the alternative, meteor add ultimatejs:tracker-react, which is a kind of extension on reactMeteorData

1 Like

Ooh, I like it!

At first, I thought this would be a mistake because it’s good to isolate reactivity, but I think the way I would use it is just put this mixin on my top-level component. That way, I still get to have pure components all the way down, but I don’t have to worry about only part of the smart component being reactive.

Here’s the link for the lazy:

1 Like

by pure components, do you mean dumb components? :smiley: components that rely purely on props passed?..

I need a good pattern for optimizing tracker reactivity in React, but haven’t really gotten into it yet :smile: do you have a draft on Tracker in React somewhere? (since I know you’re doing the guide :wink: :wink: )

So just to clarify, we can get reactivity without needing to add React from atmosphere by using Tracker-React package with NPM React, right?

1 Like

Yes that’s correct. Also to clarify, I prefer the terms “smart”, “reusable”, and “pure” over terms like “dumb”. These are the terms we use in the UI section of the guide.


haha, I’m sorry. I was just wondering if we were talking about the same thing. I don’t mean to be rude, negative or whatever. ‘Pure’ is actually a nice way to put it :smile:

1 Like

Or one more alternative https://www.npmjs.com/package/react-komposer from KadiraHQ , it’s support both ways: node and meteor

1 Like

Thanks for your replies. Being new to Meteor/React, it seems the three different methods offered above all address the same issue --making Meteor’s reactive data available to React’s components.

Would someone please explain the main differences, use cases, implications, etc. between the three solutions?

1) react-meteor-data by MDG? (atmos)
2) tracker-react by ultimateJS (atmos)
3) react-komposer by KadiraHQ (npm)


When in doubt, use MDG’s solution.

1 Like

when in doubt, learn, investigate, explore, experiment, test, validate, in context
when sure, do the same, context may change over time
@dk0r good question

  • in react world mixins are deprecated

• react-meteor-data and tracker-react are mixins and compose data inside component
• react-komposer create a container with data that children need and pass as props


Thanks for the explanation, though I’m still not certain what the implications are between how react-meteor-data & tracker-react passes data around versus how react-komposer does.
–Why does it matter that react-meteor-data & tracker-react pass data in at the component level as opposed to react-komposer which passes in data via props?

Regardless, according to casperandersen’s reply, it would seem that using react-komposer might be the best approach as he stated that React has deprecated mixins (is this accurate?).

Mixins are still alive and documented:

However, it is true that some parts of the React community don’t like mixins anymore.

I’ve been curious on how this will work for developers trying to use only ES6? Will Meteor have an ES6 way of dealing with meteor data? What we do at the company I work for is have a base Component = React.createClass({mixins:[ReactMeteorData]}) and then we inherit from it for all of the rest of our components using Subcomponent = class extends Component() which seems a little hacky but we haven’t come up with a better solution yet.

1 Like

This issue can shed some light on the matter.

  • https://github.com/facebook/react/issues/4023
  • mixins is for instance an issue when you use class Name extends React.Component
  • ES6 classes has no notion of mixins
  • React.createClass is moved into a separate module
  • mixins is not really looking like a contestant for best practice (but true, not officially deprecated)

As @sashko said.

1 Like

I guess outside of what the general “best practices” are, my personal view is that I would much rather be able to add functionality to a component rather than introducing a new wrapper for every single function. It’s great that ES2015 has inheritance, but “inheritance is not for sharing code” - you can only inherit from one class at a time.


I have been using the react-mixin npm package to enable reactivity with components that I write with ES6 (class Name extends React.Component), and its really easy too. For instance, If you have a component Main: ReactMixin(Main.prototype, ReactMeteorData); and the mixin works (at least for me so far).

However, I am aware that this is no longer best practices, so I’m interested in updating my code sooner than later. I’m just unsure really what the difference is between using React.createClass{()} and class Name extends React.Component.