Proposal for a new, higher level structure for containers

[tomitrescak]

Hi, I just finished conversion of my large project to Mantra. It was a bit of work, but things are now much clearer. Yet, having around 75 containers and 120 components, I am a but worried about evolution of Mantra. If some new cool things will happen, I will have to redo major amount of components. I guess, the most prone to this are containers. What I propose, is to create a higher level representation for containers, which are less prone to fundamental changes in package structure and I think also improve learning curve to new adpoters. Long story short. Here it goes:

export default class Container extends MantraContainer {
  @composeWithTracker
  composeModel({context}, onData) {
    const {Meteor, Collections} = context();
    if (Meteor.subscribe('sub').ready()) {
      const comments = Collections.Comments.find().fetch();
      onData(null, { comments });
    } else {
      onData();
    }
  }

  @composeWithPromise(1)
  composeOther({context}, onData) {
    // ...
  }

  @compose(2)
  composeYetAnother({context}, onData) {
    // ...
  }

  useDependencies(context, actions) {
    return {
      create: actions.comments.create
    }
  }
}

I propose a simple class that extends a parent Mantra container, and uses decorators to mark the composer functions. The parameter of the decorator decides the order of the composer. To inject dependencies and register actions.

Having the class as a container would also allow better linting and typechecking (e.g. for typescript). Please also see below, what can be achieved with static typechecking with typescript (and possibly a future linter for Mantra). So, what do you think?

[rolfnl]

While I understand where you're coming from, I think it doesn't really make things more easy, the learning curve for new/existing adopters would be higher imho (it adds complexity). Or maybe it's just me, but I don't like decorators (and generator functions) yet.

But anyway, maybe it should not be something of the core idea, it could also become part of an "advanced mantra" section in the guide (or linked to from the guide), or some section with "ideas for larger applications".. dunno.. in any case, what's good is that mantra is opinionated (wether you like that or not), so it should be clear if this is part of the official spec or not.

[tomitrescak]

Hi, thanks for your opinion. I think I will create a separate package only for those that are interested in order not to impose my opinion on anyone ;)

[arunoda]

Decorators is a nice concept. But, we need to Mantra to take the functional approach. So classes definitely not the solution.

I don't like the idea of optimizing the code for linting and typechecking

I know there are a lot of boilerplate now. If you look at closely, we use common set of code for composers. We can have a high-lever composer library for meteor called meteor-composers where we can generate a composer function with a single line.

Also, composeAll is a nice pattern.

With all these, we could automatically generate composers hopefully via some tool. (May be with a GUI).

This is my take on this.