showChildView(selector, view)

[jamesplease]

It would be cool if showChildView created a region for you 'on-the-fly,' if it didn't exist.

More generally, I would recommend completely get rid of region names and only use selector strings as region identifiers. There's little reason to use two strings when the one works perfectly fine, I think.

[jamesplease]

I made this change in my own applications, and now I don't ever deal with regions directly. I think this is a good thing!

The code (this goes in my base View class, which is just a LayoutView):

  // Update `showChildView` to coerce the region, if it doesn't exist.
  // Also, return the LayoutView instance rather than the Region.
  showChildView(selector, view) {
    var regionName = this._generateRegionName(selector);

    if (!this.getRegion(regionName)) {
      this.addRegion(regionName, selector);
    }

    this.getRegion(regionName).show(view);
    return this;
  },

  // Update `getChildView` to also accept a selector as an argument
  getChildView(selector) {
    var regionName = this._generateRegionName(selector);
    return this.getRegion(regionName).currentView;
  },

  // Given a selector, return the name of the region.
  _generateRegionName(selector) {
    return `r-${selector}`;
  },

Usage:

// old
Mn.LayoutView.extend({
  regions: {
    navContainer: '.nav-container'
  },

  onShow() {
    this.showChildView('navContainer', new Nav());
  }
});

// new
Mn.LayoutView.extend({
  onShow() {
    this.showChildView('.nav-container', new Nav());
  }
});

:heart_eyes:

[ahumphreys87]

:+1: nice syntax. I see this fitting nicely with #1976 which Im going to pick up after 2.4.2 is gone

[jasonLaster]

heh - i like names for things - but i hear ya. I'd rather talk about the app's nav, than your dot nav container selector element thing... but yea, that's hyperbole, i see your point too. just gut reaction.

[jamesplease]

I'd rather talk about the app's nav, than your dot nav container selector element thing... but yea, that's hyperbole, i see your point too. just gut reaction.

It would support the UI hash.

[jasonLaster]

yea - but do you ever want to select the region's UI... that seems like the wrong place for the region to be defined.

like - if you have an app w/ a nav region and a signin button. only one should be accessible from the app layout, right?

I think there's probably a middle ground here, but ya know.... And honestly, if you debate me i'd probably agree that a selector + ui.name is a fine solution.... especially when you drop the cognitive overhead of thinking about regions. so you might win the debate.... ughh, i think you already have... i guess.

[jamesplease]

like - if you have an app w/ a nav region and a signin button. only one should be accessible from the app layout, right?

Ah, really good point, here! @ui could possibly be tough to use here...

especially when you drop the cognitive overhead of thinking about regions.

Yeah, this is the crux of my current thinking...relegating Regions to being an implementation detail that most folks don't ever need to worry about. Honestly, though, I need to think more about the benefits of using something like a region over just delegating to a simpler DOM interface for manipulating elements.

[ianmstew]

I like the idea of dropping the cognitive overhead of regions, and @ahumphreys87's work to eliminate the region's wrapper element is a big part of that. I would love to see regions transparent to the average user in 3.0. How this particular API fits into that picture I have think more about, but I like the direction its headed.

[ianmstew]

I really like this, the more I think about it. Those region hashes are redundant for me 99% of the time (until I want to explicitly empty a region).

[jamesplease]

I made a BaseView that hides regions from me entirely, and it is truly awesome.

I'm convinced that Regions are unnecessary for the consumer of the lib

[RohovDmytro]

What about situations, when I pass a region variable into another submodule and render some stuff there? I use this pattern a lot. And it won't be enough to just pass a selector. An $el should be provided at least.

[jamesplease]

@rogovdm I'm confident that your system can be reworked to not use regions.

The most similar approach to what you're doing now would involve passing a jQuery object or node reference, but I wouldn't recommend doing that. Instead, you can either:

1. tell the view what to render (and the view itself has a reference to each constructor that it can render)
2. pass a "child view" instance to the "parent view"

I tend to use 1 for all of my nested views, but I use 2 when showing child views into the "base view" of the app.

[rafde]

I don't see this in next release

[paulfalgout]

It isn't. Anything non-breaking was moved to 3.x