Introducing Mantra - An Application Architecture for Meteor

That’s awesome. I’ll check it out.

I checked you code and It’s pretty nice. We can show it as a sample app. I like it :smile:
How about the experience using Mantra?

What are things you don’t like or you think need to improve?

2 Likes

Ok! I might need to finish off some other stuffs and clean up the code. =)

I like the way how Mantra deals with actions and containers. It was a little bit confusing and frustrating at the beginning as I needed to learn injectDeps and komposer. But once I got the hang of it, everything was very smooth. I knew exactly where my code was located.

Functions, methods, client-side validation ===> actions
Subscription, state management ===> containers
UI ===> components

One thing that I kinda struggled with was user authentication. At first I did user authentication in layout component and for some unknown reasons, it didn’t work. So I made a require-login component to restrict content. It would be awesome if you could provide us some basic recommended user authentication.

Currently, I’m tinkering the app with react-intl and react-motion. Still deciding where to put those. Component? Container? Will update the app as soon as I’m done with all these.

All in all, Mantra is awesome. Clean and straight to the point. Can’t wait to see Mantra module system! :heart_eyes:

1 Like

This is decently go into your components. Containers only take care about data loading.

1 Like

I agree. We need to have some good getting started documentation.

3 Likes

Hi arunoda & others,

I’ve played with mantra in the previous days, and I have 2 questions:

  • There are 2 places for methods: server/methods and client/modules/**/configs/method_stubs. Should I write a method stub for every method to get latency compensation? Are Meteor’s isomorphic methods considered bad practice? If not, where should I put them?
  • What’s the recommended design pattern for handling the authentication logic (in router? in MainLayout?)
3 Likes