As I promised on Friday, Here’s mantra.
Or you can directly jump into:
- Specification: https://kadirahq.github.io/mantra/
- Sample App: https://github.com/mantrajs/mantra-sample-blog-app
Have a look at it and let’s discuss.
As I promised on Friday, Here’s mantra.
Or you can directly jump into:
Have a look at it and let’s discuss.
Why did you choose enzyme to test your UI’s and also put your tests in a test folder for each component?
Just asking about some design decisions, not trying to be critical. Awesome job!
We wanted to unit test UI components. Enzyme does a good job on that.
We could have used react’s normal test utils. But this is easy. (and uses react’s testing tools behind the schene)
Putting tests near to source is very logical.
And that’s how normally, these days most projects do.
To be honest, even after reading the spec, I don’t really get what Mantra brings to the table.
Maybe it’s because architecture is such an overloaded word, but to me it just seems to say: “If you’re going to use meteor, use es2015 modules and react as view layer”. Am I missing the point here?
That’s pretty much it, although you also missed use data wrappers for components.
Congrats, it looks very nice!
From the directory structure in the spec, it seems as though SSR is not be possible (unless you change that part of the specification). Is there a reason to suggest putting all of the ui components in the client folder, and not a shared space, considering the inevitable march towards SSR?
and the guarantee of a stable target. That’s worth a lot in business decisions. Just imagine how much money was wasted when it was decided to drop blaze/.
Actually, in order to move to a common place, we need to put the code in imports
directory in Meteor. At fist, I thought it’s not nice. That’s why didn’t put it right now.
I’m looking for a way to avoid imports
directory. If it’s not, we need to put files into the imports
directory in the root level. Actually, moving to that is very easy.
Just copy all the files and keep the client/main.js
.
If you’re going to use meteor, use es2015 modules and react as view layer.
In the near future, we are building a tool a called mantra-linter, which can see whether your app is following mantra or not by statically analyzing your code. With that, it’s very easy to work with teams since you are everyone follows the same way.
Then, it’s okay to add and remove team members from an app. That’s something very hard to get in a Meteor app these days.
Like that there are many. But, if you are looking to build your very quickly does not to follow rules. May be mantra not the solution you are looking for.
It’s awesome that you and your team share all the stuff that you do for your company. It’s nice to see what other teams do. I and some others currently go with https://github.com/meteor-space. It’s a framework / architecture for Meteor.
Interesting, you guys trying to do it with view layer independent way right and build some framework level tools. Good stuff. I’ll have a more deeper look at that.
We try to based on React and a bit of functional approach, while without not implement the framework part.
I just finished a first draft of an app based on Mantra. It’s a boilerplate or a starter kit. check it out https://github.com/MaksTr/meteor-mantra-kickstarter
it’s for latency compensation using minimongo. You do not need them if you are fine with waiting for the server response to update your app
This is awesome. Thanks.
I really like this structure but I can’t for the life of me get the dependency injection to work. Anyone have an idea?
Here is a repo that replicates my problem.
It’s the same reason that people all use camel case… it’s just easier if everyone is on the same page.
It would be nice to see an illustration of how mantra components (react-komposer, react-simple-di, react-mounter, etc) fit together and what are their roles (I’ve read the documentation) An even better illustration would include the role of Tracker and how mantra augments, facilitates, or advances the Redux. Ultimately, I’d like to know if Mantra allow me to take Redux and Flux (ZenAction, ZenStore) of the table? A nice illustration would help me avoid a lot of background research (depth vs breath).
Will do it soon once we finalize our module system.
I made a simply quiz based on Mantra. http://react-explorer.meteor.com/. Repo: https://github.com/sammkj/react-explorer