Waiting for packages to catch up to 1.3 & React?

1

Sorry, maybe too opinionated/subjective of a question:

I have an old Meteor app that ought to be rewritten, since it was my first complete project. I’ve gone back and forth on whether to stick with Meteor, or totally start over with a more decoupled stack.

I was really excited to see 1.3, but it looks like the React implementation in Meteor isn’t exactly ironed out (i.e. multiple overlapping approaches), and many of the packages that would make Meteor an attractive option don’t have React versions (probably for this reason).

Is it worth it to try to refactor this app now, or is the general sense that React is still finding its spot in Meteor? I kind of feel like if I revisit this in 3 or 4 months, the dust will be much more settled.

2

I find the current Meteor + React story to be pretty solid. There are definitely a few options to consider, but options aren’t necessarily a bad thing. Deciding on createContainer, TrackerReact or react-komposer for example can sound daunting, but it’s not really that much work to investigate each option a little, then decide for yourself. If you’re crunched for time just stick with MDG’s current (draft) React guidelines/recommendations.

A few extra notes:

  • Be prepared to find (or build) alternatives for some of the Blaze based packages you’re used to (e.g. AutoForm).
  • The shift to npm is awesome, but don’t be afraid to continue to leverage Atmosphere based packages (if you can’t find a reasonable npm alternative). I’ve seen a lot of people try to shy away from Atmosphere completely with 1.3; trust me, it’s still early; save yourself the headache and leverage both to your advantage.
  • The React landscape continues to change irrespective of Meteor’s React integration. 3-4 months is a long time in JS fatigue land, and anything can happen, but I’m pretty sure the knowledge you gain by jumping into React now won’t be wasted in 3-4 months time. The core React concepts aren’t going to change much over such a short timespan, so even if your container pattern (or similar) needs to change in a bit, the majority of your app shouldn’t have to change that much.
3 Likes
3

Re overlapping approaches, at least in terms of basic React support, this is no longer a question.

Meteor v1.2 used a ‘react’ package, which is now deprecated.

Meteor v1.3, the way forward is clear:

  $ npm install --save react react-dom

and

  import React from 'react';

This of course works with any meteor package written for 1.3+ and also npm package. Everything works great. No CSS imports yet though.

But yes, it’s true… 1.3 final is only just about to come out, so will take Atmosphere package authors some time to hop on board, assuming they want to change or support multiple front end stacks. Of course, it’s also no problem to use Blaze templates in react, with gadicc:blaze-react-component, for example:

import React from 'react';
import Blaze from 'meteor/blaze-react-component';

const App = () => (
  <div>
    <Blaze template="itemsList" items={items} />
  </div>
);

Or with thereactivestack:blazetoreact:

const ItemsList = BlazeToReact('itemsList');

const App = () => (
  <div>
    <ItemsList items={items} />
  </div>
);

@sashko, we should mention this in the guide, which currently only talks about using React components inside of Blaze (i.e. the other way around), although the React Tutorial does show how to wrap templates by hand).

4

So can you enlighten me about what would be a safe set of packages (npm and atmosphere) to use with React and Meteor 1.3 right now? I know I could read the guide, but I’d just like a brief bullet point list from someone (or more than one person) who’s brought something into production (fine if it’s not fully released yet, I just want to exclude hobby shenanigangs; has to be paid work in whatever sense) on that stack.
Last time I’ve done some research on React with Meteor it seemed like there were no satisfying answers for things like “where do I put all my data / where does it come from”. Any insight would be appreciated!

5

This is the set of packages we decided on as the basis for our production code https://github.com/tomRedox/simpleCRM/. It will evolve as the project does no doubt, but it’s our current thinking.