Clarify module meaning

[Kshatra]

I would like to clarify for myself the meaning of module termin related to Mantra.
Does module represent single view/page or does it represent collection of pages related to each other with common sense? One way or another there is some problems i feel in design concept.

Example 1: module represent a single page/view. So, if i add a custom accounts management to the project, i end up with 3 modules just for this one purpose: userList, userAdd, userEdit. I see a problem in this as module should represent one concept (like it does in Django for example).

Example 2: module represent a several pages/views. In this case userList, userAdd and userEdit view are gathered up in one module that is seems correct for me. But all actions/components/conteiners from all this pages/views are ending up in one directory. Sometimes it's really hard to tell which component belongs to specific view. I tried to create a sub-directories for each view, but this approach has a bottleneck in how Mantra handles actions. I cannot have an action defined as {viewInsideModule: {component: {cmpAction}}}. I think it may be related to #199 . It would be nice to have n-deep tree of actions. That would allow any kind of namespacing: per-module or per-view inside the module.

[fermuch]

This is how I use modules:

• My app has a sidebar, with different routes ("tasks", "places", "activity", etc)
• Each of these routes is a module.
• Each module has different containers and components. For example, "tasks" has a container to list the tasks, other to set filters, another to edit tasks...

There's also an "accounts" module, that contains all the logic of login/logout/register/invite, and some other minor modules.

The advantage of using modules is that it becomes quite messy if you have only one (core), with lots of containers and components, but dividing in sections of your app makes it easy to find what you're looking for.

[VikR0001]

Is anybody still using Mantra? If so, why? @arunoda has A) abandoned it and B) refused to turn it over to the community to maintain. It's very incomprehensible because he's been fantastic about letting his other projects be turned over to the community.

[Kshatra]

Each module has different containers and components. For example, "tasks" has a container to list the tasks, other to set filters, another to edit tasks...

Yes, but suppose that "list tasks" and "edit tasks" is a top-level containers (that are directly mounted into app layout), while "set filters" is used somewhere inside "list tasks" component.
What i don't like is a fact that all these containers are ending up in one folder inside a module. And if there are many sub-components like "set filters" it's realy hard to tell "what uses what" without using naming conventions.

[smooJitter]

Yes @VikR0001 I'm sort of still sticking with the idea of mantra. I love that I don't have to rely on redux as much. Frankly, there's not much to the framework. It my be worth looking at alternative ways of working with containers. While react-simple-di is still useful, recompose offers a better set of utilities for composing components (react-komposer is built into the mantra core).

So far, still my goto app framework.

[VikR0001]

@smooJitter Thanks for those thoughts. I was thinking I was going to have to rip all my code out of Mantra and move to whatever it says in Meteor Guide. After hearing from you I guess I can stay in Mantra for the time being.