You can use a lot of Meteor Atmosphere packages. But for reactive data you can use react-komposer.
That’s what we are using for Mantra.
1 Like
We are releasing an official meteor and react guide with 1.3, which will answer these questions.
7 Likes
Thanks for the info all, Mantra looks interesting, though there are some things about the structure I don’t get. I am new to React so maybe that’s why. I’m glad to see that the official guide will be answering these though. And thanks for the info on the react-meteor-data package. I wasn’t sure if I still needed to install the Atmosphere react package as well.
Oh that’s awesome news. Looking forward to it!
Not that it is urgently needed, but I think a note like that in Mantra or the Mantra example blog app might clear up some questions about UI components in Mantra.
Without any guide from MDG for React and Meteor the best alternative is Mantra. The specification from kadira is also really good. They have also given some components to build things like containers and DI. You can use those or roll your own as they are quite simple to do. The important point my team took from Mantra was how would we plumb all the pieces together. We did tweak some pieces according to our own needs but to me Mantra was a really good starter.
I’ve been looking into this a bit more the last few days. From what I understand, React Mixins (which Meteor uses for the getMeteorData method) are going away. They are unofficially deprecated. I’ve also heard that ES6 classes and extending React.Component will be preferred over using React.createClass(). Since ES6 classes don’t support mixins anyways, there have been a couple of packages that fill the gap. So MDG would need to rewrite the mixin as a class to extend, or scrap the getMeteorData idea altogether and find another alternative; yet another uncertain future.
Worse yet, the React community seems to be pushing React Containers, or React components that have no state, it’s all done via props using an external function (container) to supply the data. The community really wants to get away from states for the added flexibility of swapping out one container or component for another to reduce code duplication. I thought this article explained it pretty well: https://medium.com/@learnreact/container-components-c0e67432e005#.btwnk1n2z
After I finally bought into the idea of putting HTML and logic into the same file (JSX), now we’re back to splitting it out into two files, one for component, one for container. This lead me to discover the react-kompser package, which eventually led me to Mantra. I’ve seen Mantra several times, but I never understood its purpose until now.
Mantra is basically a set of best practices for working with React and Meteor. The spec says nearly the same thing, only I didn’t understand what modern React meant. If you look at the React docs and most tutorials on the web, you’ll see usage of props and states, but I guess modern React means props and containers. So in Mantra, I now understand Components and Containers, but I’m still not clear on where Actions fit in. I’m also trying to figure out how Mantra’s directory structure would accommodate an app with multiple sub-apps. The flexible Meteor structure allows me to do something like:
- Client
- Core
- layout.html
- helpers.js
- routes.js
- App1
- index.html
- index.js
- routes.js
- App2
- index.html
- index.js
- routes.js
- Core
But I’m unsure how I could get the same containerization of apps using Mantra. That and when/where to use Actions are my two biggest questions right now.