Customizing

[smooJitter]

Summary of the issue

Is it posible to use .yml to customize file structure of a generated module?

Steps to reproduce

1. step 1
2. step 2
3. ...

Environment in which this issue happens

1. CLI version:
2. node.js version:
3. Operating system:

[macrozone]

hi @smooJitter sorry for the late answer,

what exactly do you want to customize?

I already customized the modules-directory so that you can use meteor 1.5. lazy loading.

I now want to also make the libs folder more customizable

[vladejs]

@macrozone , In what version of mantra-cli was added the changes for meteor 1.5?

[macrozone]

@vladejs mantra cli 0.5.1.

configure modulesPath: imports/modules

I now updated RELEASE_NOTE.md, sorry for that.

[vladejs]

@macrozone , there is some work to do here. Currently I can set modulesPath variable, but when I create a component/container, tests are still being created under /client/modules/... instead of /client/imports/modules/...

[smooJitter]

The customizations were really necessary. When I generate a new module, I like to have it pre-populated with a standard set of components and associated containers and actions ( EntityList, EntityDetail, EntityNew, EntityEditor, and EntityFilters for components. CRUD from actions). where Entity corresponds (mostly) the moduleName. I've done a little hacking to figure it out.

I really do miss the activity on this project. It is a very solid framework. I still why it was abandoned. I understand the personal issue may have gotten in the way, yet I still wonder if the original contributors still believe in the mantra approach. It would be great to at least hear a few suggestions. I noticed, even mantra-talk is gone.

[vladejs]

Hi @smooJitter. It's a shame indeed, that this wonderful architecture get abandoned by the community.

I truly believe that Mantra could be adapted to keep up with the latest technologies out there. If you are interested, I upgraded Mantra to be used with this stack:

• MobX 3.0
• Meteor 1.5+

​I modified mantra-core by removing old react-komposer 1.x and included Mobdux, a thiny wrapper for mobx-react library wich has the advantages that you don't need to decorate your dumb components with @observer.

For more info, you can check out the Project which I called MantraX here: https://github.com/vladejs/mantrax

[sungwoncho]

@smooJitter I sympathize with your concern. As a maintainer of this CLI, I am sad to see Mantra being abandoned. While I would like to see a continued development, I have been using neither Mantra or Meteor for more than a year, and I am not in a suitable position to lead or contribute to the framework.

I agree that Mantra is a solid specification and has potential. Therefore, in the meantime, I would like to encourage the community to step up if interested in maintaining the CLI project along with @macrozone.

It would be nice to see some handover effort from @arunoda, so that Mantra can be further developed under the community governance.

[macrozone]

@vladejs ok, can you open an issue? should also not be too hard to fix. PR welcome

[smooJitter]

That's the beauty of Mantra. There isn't much too it. There isn't a lot to maintain. The only thing @arunoda vision of where he saw it going, and what constraints he was concerned about. I simple Medium article, thats it. I don't know how much I could contribute but I would be willing to have some dialogue about various issues. I think it would be best to have the discussion via Meteor Forums, a 3 - 5 part series. (WARNING, TYPOS are likely, no time to proof this)

1. Enhancing the core class (i.e., app = createApp(context)). @sammjk has already offered a few good extension (vis mantra-plus) on extending the core with mantra and apollo middleware. I would like to consider the communities view regarding extending the core like so.

export class App {
  constructor(context) {
    // standard 
    if (!context) {
      const message = 'Context is required when creating a new app.';
      throw new Error(message);
    }
    this.context = context;
    this.actions = {};
    this._routeFns = [];

    // @sammjk extensions,
    this._moduleWillLoad = []; 
    this._moduleWillInit = []; 

    //  with this the core can respond to state updates
    this.context.Store.subscribe(this.onStoreUpdate.bind(this));
    store.dispatch(appActions.appInitialized());
  }

  onStoreUpdate(){ ... }

  ...

@markoshust have offered a few simple but use extensions to the core ( hymn-core and hymn-di), most importantly, he address the promise of name spacing mantra actions. The question here what might be some interesting ways to enhance the core?

2). Redux actions and action types. This is probably one of the most interesting opportunities. Redux is here and whether we support it completely, I do think it provides solid support for local state (e.g., ui things like buttons, drawers, toggles, etc) The issues with redux, theres already to much complexity ( etc, actions, reducers, actionTypes ) while mantra helps reduce the reliance of redux (almost to zero), what are some efficient ways to incorporate redux, particular better integrate redux actions with mantra actions. Should we store a load redux actions the same way we load mantra actions. Since mantra relies on limited use of redux, might it be possible to adopt one of the rogue approaches to reducing redux boiler (e.g, jumpstate is especially interesting)

3). graphQL containers, actions, mutations, and queries. Good news is apollo has done a great job with graphql container, furthermore, recompose provides a more flexibility in compose components. In interesting question here how should we integrate mutations and queries. Should with write graphQL queries in the actions? Should we write them in the containers? Or should we write them at the component level.

4). Mantra beyond react-komposer, frankly react-compose provides access to tracker which is really only useful in the meteor context. Furthermore results are return via the data prop. graphql containers also return data on the data prop. Fortunately, for me at least, graphql has a nice way to get around it.

5). What's up with?

   load(context, actions) {
       // do any module initialization
    },

There's a lot to explore with this. What did @arunoda have in mind with this. Furthermore, what about passing parameters or functions to app.init(...). These features seem to be under utilized. I haven't seen a repo that leverages load(...) other then when used with method-stubs. Speaking of method-studs, whats the conceptual equivalent if one is using say GraphQL on Firebase as remote persistent state.

Essentially, It would be nice to hear some ideas with the main theme of "Mantra for React" or "Mantra Beyond Meteor". Mantra was intended to be front-end "react" framework, and not a meteor framework. Unfortunately @arunoda adopted too many meteor dependencies (Meteor, FlowRouter, React-dict, Tracker etc), too many Kadira dependencies (react-komposer, react-di, FlowRouter) with only a promise of how mantra can be used beyond. It still provides a fantastic way of organizing the code, and I support the framework. Franking, I think @sungwoncho was the last man standing in this game. The CLI may have a few bugs here and there but it too is already a great tool. It can only go further if the framework is expanded.

Note, I'm using react-native so I don't rely on the meteor context (react-native-meteor somewhat). I only hung around because I was waiting for Mantra's most import promise (future proof).

[macrozone]

@smooJitter Supporting redux and graphql is partly supported with mantra-cli, at least you can define templates for your containers that have the basic boiler-plate (add connect and graphql hocs).

@remolueoend, me and others in my company are currently using mantra-cli (havily) in redux/apollo/react-native projects and we think about how we can make it easier to scaffold actions and reducers. The actions folder in these projects contains non typical mantra-actions, but redux action creators and we have an additional folder reducers per module, which we combine in one main-reducer.

We do not use a global context anymore in these (non-meteor) projects and therefore neither mantra-core, react-simple-di nor the module load functions. Actions are therefore also not bound to any context.

I think arunoda's idea of mantra-context was that you can inject and therefore mock meteor-specific stuff into your containers and actions which makes unit-testing of these components easy (without booting meteor at all)

On the other hand, a global context is not so common in the rest of the react-community and therefore should be optional in mantra-cli.

So my bottom line:

• general structure of mantra (modules and every module has components, containers, actions) fits for every react project and also for every way of state management
• mantra-cli should be more configurable for the different flavors (meteor-react-tracker, meteor-redux, meteor-apollo, react-nativ-redux, with/without context, etc.)
• mantra-cli might be the missing cli for react projects (angular has one, vue has one). create-react-app is great for initial scaffolding though, but has no option to scaffolding your components, actions etc after that. In fact you can start with create-react-app and use mantra-cli after that

I will create a roadmap for mantra-cli in the next weeks. Please leave issues or comments for features that you want!

I am also interested if anyone knows whether yeoman might also be a valid option to use as scaffolding engine.