define application region as function

[taburetkin]

define Application region in runtime

as i can see, there is no chance to do it right now, because user can pass to region property region class

if this improvement will be accepted: #3569 , then i can offer this kind of improvement for resolving this issue

Application

  constructor: function constructor(options) {
    this._setOptions(options);

    this.mergeOptions(options, ClassOptions$7);

    //this._initRegion(); //remove this line;

    MarionetteObject.prototype.constructor.apply(this, arguments);
  },
  _initRegion: function _initRegion() {
    var region = this.getOption('region', true); // old line: var region = this.region;

    if (!region) {
      return;
    }

    var defaults = {
      regionClass: this.regionClass
    };

    this._region = buildRegion(region, defaults);
  },
  getRegion: function getRegion() {
    if(!this._region) this._initRegion();
    return this._region;
  },

this will help define application as a function, and allow to initialize a region only if a region will be accessed, even after start of application

[paulfalgout]

I am ok with region accepting a function returning a region, but I think the pattern to follow would be more like how a view class can be a function on collection view.

What is unique about this situation to my knowledge would be that this would be the first instance of anything that can be defined with a function. I also can't come up with a suitable use case for why this needs to be, but it seems straight-forward enough to implement.

@marionettejs/marionette-core ?

[bazineta]

It does seem straightforward.

However, I think I'm still confused as to our rationale for having this facility in Application at all, as it to me seems to be a point of confusion; certainly, it was confusion that stemmed the initial discussion.

That is, Application has a feature-limited version of something that View has a much more full-featured version of, and I'm not sure why. The demo for it linked from the docs does not to me make a compelling case for why I'd even want it in the first place, and as such I've never used it, yet it exists, so there must be some excellent reason that I'm just not seeing.

If it is indeed the absolute best way to handle some use case, then I think we should make it as useful as possible, but if not, then to me it seems that View does this better.

[bazineta]

As an example, even a complex application is, in general, well-served by having just a single Application instance. Our hypothetical app needs a root View, and let's say that root view is going to own body, a reasonably common thing for it to do, and it's going to manage a few regions, say #nav, #content, #footer. Basic stuff.

Does having region in Application facilitate this particular use case? If it doesn't, then are we putting stumbling blocks in place?

[paulfalgout]

I don't want to hijack this issue too far, but I think the question comes down to what comes first. Some people prefer view->region->view->region->view while others, myself included, prefer region->view->region->view to start the lifecycle. It is a very small difference, but both patterns are pretty broadly used.

There is an argument that you can setup views all the way down where parent views setup their own children in onRender but it is completely reasonable to suggest the views should rarely ever show children in which case you have to send regions somewhere else.
So beyond making an easy place for Application to show the root view, it is an easy place for building the view tree in a mediator object. so that it's app.region->view(pass view region to new app)->app.region->view(pass view region to new app)->app.region->view

At one point Marionette was considering adding "sub-apps" to the library but it was determined to be too opinionated for the library and Mn would focus on views. However adding a region to Application allowed for an easy start to that pattern.

sub-app xref: #2201 #2026 #2200 #1321

app region xref: #2279 #2326 #2770

[taburetkin]

i think i can mixin State into the View
maybe i even can mixin Radio into the View (but object already has it)
but is it possible for a view do not have Dom element at all?

and what if we are talking about ui control
in my opinion ui control is not a view and is not a model.
its a wrapper which can or can not have view or model
and Application could be that ui control, in my opinion