Hi,
There are a lot of things happening around Mantra and it’s very excited to see such a level of community activity in a short time. (less than 2 months)
As some examples:
And there are a lot of things other things and experiments are happening in the community.
Take a tour into the World of Mantra.
\o/
Awesome Awesome stuff!
And look at you with the conversational UI =P
How mantra will evolve when the new Meteor Data layer will be released ?
Mantra is said to be ‘‘future proof’’, so how will you make the transition to the new data layer ?
Apollo should be a separated data layer tooling and Mantra is a client side architecture so I understand that it should be simple to integrate them… btw, the tooling around Mantra and all that stuff is impressive! Congratulations to all contribiutors and Kadira team.
The Mantra-Atom package is heaven sent!!! I’m finally catching on to Mantra, and meteor in general. The Atom package has done more than any article or book I’ve read. The speed at which the tooling came on line speaks to the kindness of the architecture, Mantra (sound repeated to aid concentration in meditation) captures it best. . I finally understand the expression “easy to reason about”. I still believe we can use a solid visual illustration of how the components fit together. Now that we are looking out towards interacting with a more complex application and remote states, it would be nice to visualize how they work together and where Mantra fits.
@skini26 as @juliancwirko It should be easy as changing our container code to work with Apollo. Anyway, integration of Apollo will be much simpler with any app.
I updated the blog with showing the current best approach to learn Mantra.
I’m copying that here as well.
This is the current best approach to get started with Mantra.
@arunoda this approach is for getting STARTED using Mantra right from the scratch. Any guidance about converting an existing production app in to Mantra spec would be really awesome.
As I am assuming it is not going to be 1-to-1 mapping of the conversion. So, any best practices or possible approaches using sample apps to conversion would be very helpful. I am assuming lot of apps on the fence waiting for the changes to stabilize to reduce the risk associated with conversions of this type.
I will try some experiments. Are you referring to an existing React Meteor app or a Blaze app?
I was referring to existing production Blaze app, since most apps will be in Blaze. The issue is, going in to the world of Mantra would be require big refactoring and most apps when it comes to refactoring usually go incrementally to reduce the risk.
So I am not sure what would the starting point and approach - should I first convert the view in to React to get components and then refactor one more time to Mantra specific architecture, or first write tests using Meteor 1.3 and then refactor it in to Mantra straight up? or any other approach. It seems there seems to be a gap in knowledge here. So any guidance for refactoring existing blaze app would be awesome. Thanks
Okay. It’s existing Blaze apps. I’ll check what we can do about this.
I’d suggest first converting all your Blaze templates into React components first. That’d take a decent amount of work, but I’d wager it’d be worthwhile in the long term.
From there, try to separate the state out of each component and put them into a separate wrapping component that simply passes props down to the stateless (dumb) React component.
If you’ve gotten this far, you’re more than halfway there. So just to recap:
Convert all Blaze templates into React components (I hope you’ve been using template specific subscriptions)
Split each component into two parts: the data-fetching component, and the dumb view. These will be parent-child components respectively. i.e. the data-fetching component will simply fetch the data and pass on props to the dumb UI view component.
Now you can group these according to the modules architecture, and you’re basically almost there.