Introducing Mantra - An Application Architecture for Meteor

As I promised on Friday, Here’s mantra.

Checkout the blog post.

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?

1 Like

That’s pretty much it, although you also missed use data wrappers for components.

1 Like

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/.

1 Like

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.

1 Like

If you’re going to use meteor, use es2015 modules and react as view layer.

  • No. It’s not. It layout a set of rules which allows you test every part in your app. Simply using modules does not give you that.
  • It has standards on the directory layout and file names. Then everyone on the same page.
  • It let’s you choose what ever the data layer without changing much in your app later on. That’s something less to worry.

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 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.

1 Like

I just finished a first draft of an app based on Mantra. It’s a boilerplate or a starter kit. check it out


Hey @arunoda what are the method stubs for?

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

1 Like

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).

1 Like

Will do it soon once we finalize our module system.

1 Like

I made a simply quiz based on Mantra. Repo: