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

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.

4 Likes

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.

maybe this can help

1 Like

I think that React will rid of these pseudo Classes sooner or later :wink: This is quite weird that React plays functional approach and here we get pseudo OO Classes. Even now, we have stateless function components.
Just an opinion. :wink:

For me Arunoda’s react-komposer is very interesting. I would like to read more about it and see more examples in demo apps. There will be also Mantra which will use this approach so it could be nice.

2 Likes

Yeah but the function components are bit janky for my taste - what about prop types, component names, etc? Perhaps decorators and similar will come to the rescue.

1 Like

The mantra setup is actually really, really good. The function components are the proper use of the new recommended stateless/‘dumb’ components. component name is the name of the function. ‘smart’ components do have component names and props, but I do think correct prop type definitions need to be added to improve the examples.

1 Like

I assume you are referring to stateless components. Somehome babel detects their displayName from the variable. Even we assign them like below:

const MyComp = () => (<p>aaa</p>);

But this doesn’t work in Meteor.

for that you need to do this:

function MyComp() {
  return (<p>aaa</p>);
}

I like the first style so. I do something like this:

const MyComp = () => (<p>aaa</p>);
MyComp.displayName = 'MyComp'.

(I think this is what babel’s jsx parser does)

Yeah! It’s has an issue with propTypes. But that’s not going to help you much unless you are publishing packages to NPM or somewhere else.

I think stateless components are the turing point in React. Now it’s much like normal templates. When combined with containers, this is awesome.

That’s weird because we use the same babel transform, AFAIK… perhaps it will be better in Meteor 1.3, when we are unifying the ecmascript and jsx packages… @benjamn?

I guess one of my favorite things about React initially was OOP-style components, but I can see the benefit of a functional style as well.

I’m using 1.3, may be later on it’ll get fixed.

1 Like

I’m new to stateless components as well, but I believe you can do something like the displayName example for propTypes:

MyComp.propTypes = { children: React.PropTypes.string };

 

Automatic displayName used to not work in the first Meteor + React implementation, and this was eventually fixed/added. So I’m assuming this is in fact a bug or needs implementation and will be added, so .displayName will just be temporary.

Just a quick question, Is step 5 (meteor add modules) needed for a meteor 1.3 app?

It’s only required if you want the import / export syntax. You can also just use the ecmascript package which implies modules

1 Like

It is not needed at all anymore, due to:

modules added, version 0.5.0-beta.12

after upgrading to beta.12

1 Like

Thanks, rhywden. I must have missed where this was stated on their github.
Would you please provide a link citing this update so I can remove the step from the guide?

I don’t have a link. That’s what I noticed when I created a new project from scratch and directly updated it to beta.12

meteor add modules

told me that this component was already installed. Upon looking at the installation spam, I then discovered the line I quoted in the previous post.

We just released an easy React and Tracker integration, one can not make this easier and the implementation can’t be lighter, it’s ridiculous how easy we’ve made it.

Bonus feature: Server Side Rendering (see the clip ;))

Learn how we build easy React Components with Meteor 1.2 and Tracker using Tracker.Component:

Cheers from the folks at Studio Interact