[BUGFIX canary] Decouple route transition from view creation #10372

ef4 · 2015-02-06T21:56:47Z

This closes #9814 and #10304, which are examples of a class of problems caused by
the way the router synchronously reaches into the view hierarchy to set
outlet state. It is a significant refactor of the way the router
communicates state to outlets.

What motivates this change?

Simple examples like {{#if something}}{{outlet}}{{/if}} are
incorrect under the current model.
Richer examples like block-helpers to enable animation also
suffer. In general, the router cannot know when and whether a
particular outlet is going to exist, and it shouldn't need to know.
The router maintains a bunch of view-related state that is actually
redundant with the view hierarchy itself, leading to unnecessary
complexity.
This eliminates the longstanding weirdness & confusion caused by the
fact that we used to create new View instances and then throw them
away if they looked similar enough to ones that were already
rendered. That functionality is now covered by state diffing in the
OutletView.
We reduce the API surface area between router and view layer in a way
that should make it easier to experiment with swapping in compatible
implementations of either.
As a bonus, this changes makes outlets work in an observer-free way
that will make them easy to integrate with upcoming planned view
layer optimizations.

How does this work?

Rather than directly building and linking views, the router builds up
an abstract summary of the render decisions that have been made by
the current routes.
This state is cheap to recalculate as needed. It doesn't do any view
creation. To avoid expensive observer creation & teardown, we just
recreate the whole thing and use a setState-like mechanism to
propagate the changes through the outlet hierarchy. This gives us
optimal granularity of updates.
Actual view instantiation moves into the OutletView -- within the
view layer where it belongs. Each outlet does a diff to see whether
it should rerender itself or propagate inner changes down to its
child outlets.
To bootstrap rendering, the router creates a single top-level outlet,
after which all view creation is internal to the view layer.

Does this break any existing semantics?

No, as far as I can tell.

Could this get even better if we decided to deprecate some old
semantics?

Yes. It would be better if users' renderTemplate implementations on
Routes were required to be idempotent. Then we could eliminate a
bunch of the remaining state from them.
Similarly, we should consider forbiding calling render and
disconnectOutlet at arbitrary times that are outside the scope of
renderTemplate. It makes the programming model harder to reason
about.
Also, when we deprecate the render helper we can eliminate the
remaining use of _activeViews state tracking on the router. That is
the only remaining use for it.

rwjblue · 2015-02-06T22:09:30Z

packages/ember-application/lib/system/application.js

@@ -1003,6 +1004,7 @@ Application.reopenClass({

    registry.injection('view', 'renderer', 'renderer:-dom');
    registry.register('view:select', SelectView);
+    registry.register('view:outlet', OutletView);


I think this should be prefixed with a dash, it is private and we don't want any apps having collisions with their outlet routes...

I have no strong feelings about this, but why is it different from all these other registrations that are not prefixed? They all seem equally subject to collisions.

I guess because we consider the others public API that people are supposed to know about. Hmm.

I am unsure if the others are public api either. But regardless this offers a mild buffer from resolved alternatives.

My concern is that adding this here removes the ability for apps to use the word "outlet" as a route name (which I have done actually).

As far as why the others are not prefixed, I only see three other views being registered:

select was added intentionally as public API (to be used as {{view 'select'}}), and was therefore not prefixed.

view:toplevel and view:default have existed since v1.0.0-rc1 (see here). I am unsure if they are considered public API, but it is grandfathered in under SemVer (as far as naming collisions go) due to being present pre-1.0.0.

If your position is that this is actually a public API (for example if folks are supposed to put a file at app/views/outlet.js that exports a custom OutletView), I suppose that is a different argument, but I do not think that is what you are suggesting...

Nah, that's fine, I will add the dash.

rwjblue · 2015-02-06T22:30:25Z

This looks wonderful!

quaertym · 2015-02-07T00:04:34Z

👍

jcope2013 · 2015-02-07T01:51:45Z

👍

ef4 · 2015-02-07T02:03:49Z

@rwjblue has pointed out that this will let us remove the isTop flag that gets added by the template compiler.

And @mmun pointed out that this eliminates our last internal use of ContainerView's currentView, giving us the option of deprecating it.

This closes emberjs#9814 and closes emberjs#10304, which are examples of a class of problems caused by the way the router synchronously reaches into the view hierarchy to set outlet state. It is a significant refactor of the way the router communicates state to outlets. What motivates this change? - Simple examples like `{{#if something}}{{outlet}}{{/if}}` are incorrect under the current model. - Richer examples like block-helpers to enable animation also suffer. In general, the router cannot know when and whether a particular outlet is going to exist, and it shouldn't need to know. - The router maintains a bunch of view-related state that is actually redundant with the view hierarchy itself, leading to unnecessary complexity. - This eliminates the longstanding weirdness & confusion caused by the fact that we used to create new `View` instances and then throw them away if they looked similar enough to ones that were already rendered. That functionality is now covered by state diffing in the `OutletView`. - We reduce the API surface area between router and view layer in a way that should make it easier to experiment with swapping in compatible implementations of either. - As a bonus, this changes makes outlets work in an observer-free way that will make them easy to integrate with upcoming planned view layer optimizations. How does this work? - Rather than directly building and linking views, the router builds up an abstract summary of the render decisions that have been made by the current routes. - This state is cheap to recalculate as needed. It doesn't do any view creation. To avoid expensive observer creation & teardown, we just recreate the whole thing and use a `setState`-like mechanism to propagate the changes through the outlet hierarchy. This gives us optimal granularity of updates. - Actual view instantiation moves into the OutletView -- within the view layer where it belongs. Each outlet does a diff to see whether it should rerender itself or propagate inner changes down to its child outlets. - To bootstrap rendering, the router creates a single top-level outlet, after which all view creation is internal to the view layer. Does this break any existing semantics? - No, as far as I can tell. Could this get even better if we decided to deprecate some old semantics? - Yes. It would be better if users` `renderTemplate` implementations on `Route`s were required to be idempotent. Then we could eliminate a bunch of the remaining state from them. - Also, when we deprecate the `render` helper we can eliminate the remaining use of `_activeViews` state tracking on the router. That is the only remaining use for it.

[BUGFIX canary] Decouple route transition from view creation

mmun · 2015-02-08T07:07:00Z

👏

rwjblue · 2015-02-08T14:26:30Z

I accidentally branched for the 1.11 betas before this landed. Pulled in for 1.11.0-beta.2.

machty · 2015-02-08T16:32:51Z

packages/ember-routing/lib/system/router.js

+  var target;
+  var myState = {
+    render: renderOptions,
+    outlets: Object.create(null)


I believe this needs to be Ember.create for ie8 et al support

@stefanpenner - It was already fixed in a followup PR.

@machty

@machty pointed out that emberjs#10372 uses an ES5-only feature.

tim-evans · 2015-02-09T17:30:12Z

I'm using canary, and it seems like this refactoring broke my app.

this.connections.push(renderOptions);

this.connections is undefined. Are there other deprecations that come with this change that should be communicated?

rwjblue · 2015-02-09T17:31:26Z

@tim-evans - Can you open an issue with a repro so we can track this down?

tim-evans · 2015-02-09T17:43:06Z

@rwjblue I'll try to do this, but I'm currently in a big upgrade from 1.8 to 1.11. I'm just flagging this as an issue for now.

rwjblue · 2015-02-09T17:52:32Z

@tim-evans - Gotcha, good luck!

machty · 2015-02-09T18:38:03Z

@tim-evans I'd be on the lookout for a this.render() in an unusual place (e.g. outside of renderTemplate or action handlers), but I could be wrong.

tim-evans · 2015-02-09T21:19:31Z

@machty just checked around that, but it doesn't seem to be it at first glance.

@machty

@machty pointed out that #10372 uses an ES5-only feature.

kamal · 2015-03-03T08:58:51Z

One use case that broke for me is calling this.render without specifying the into option. Somehow Ember used to be able to look up the chain of templates to find the first named outlet?

This used to work:

renderTemplate: function(){
  this._super();
  this.render('settings/_nav', {
    outlet: 'subnav'
  });
}

mixonic · 2015-03-08T21:35:01Z

@kamal that sounds like a regression. I suggest opening a ticket (ideally with a reproduction) to track a fix.

rwjblue reviewed Feb 6, 2015
View reviewed changes

ef4 force-pushed the decouple-outlet branch from a5ab541 to ba1d1a6 Compare February 8, 2015 06:18

ef4 added a commit that referenced this pull request Feb 8, 2015

Merge pull request #10372 from ef4/decouple-outlet

b186e6e

[BUGFIX canary] Decouple route transition from view creation

ef4 merged commit b186e6e into emberjs:master Feb 8, 2015

machty reviewed Feb 8, 2015
View reviewed changes

ef4 mentioned this pull request Feb 8, 2015

[BUGFIX beta] fix ES3 compatibility #10389

Merged

ef4 added a commit to ef4/ember.js that referenced this pull request Feb 8, 2015

[BUGFIX beta] fix ES3 compatibility

4850e09

@machty pointed out that emberjs#10372 uses an ES5-only feature.

ilkkao mentioned this pull request Feb 11, 2015

Using Modal Dialogs - undefined error in canary #10416

Closed

ef4 mentioned this pull request Feb 12, 2015

Update to work with new outlets API ember-animation/liquid-fire#173

Closed

ef4 added a commit that referenced this pull request Feb 15, 2015

[BUGFIX beta] fix ES3 compatibility

ac6639b

@machty pointed out that #10372 uses an ES5-only feature.

digitalcora mentioned this pull request Apr 15, 2015

Ember 1.11 breaks rendering in the application route? #10884

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[BUGFIX canary] Decouple route transition from view creation #10372

[BUGFIX canary] Decouple route transition from view creation #10372

ef4 commented Feb 6, 2015

rwjblue Feb 6, 2015

ef4 Feb 6, 2015

ef4 Feb 6, 2015

stefanpenner Feb 6, 2015

rwjblue Feb 7, 2015

rwjblue Feb 7, 2015

ef4 Feb 7, 2015

rwjblue commented Feb 6, 2015

quaertym commented Feb 7, 2015

jcope2013 commented Feb 7, 2015

ef4 commented Feb 7, 2015

mmun commented Feb 8, 2015

rwjblue commented Feb 8, 2015

machty Feb 8, 2015

stefanpenner Feb 10, 2015

rwjblue Feb 10, 2015

stefanpenner Feb 10, 2015

tim-evans commented Feb 9, 2015

rwjblue commented Feb 9, 2015

tim-evans commented Feb 9, 2015

rwjblue commented Feb 9, 2015

machty commented Feb 9, 2015

tim-evans commented Feb 9, 2015

kamal commented Mar 3, 2015

mixonic commented Mar 8, 2015

[BUGFIX canary] Decouple route transition from view creation #10372

[BUGFIX canary] Decouple route transition from view creation #10372

Conversation

ef4 commented Feb 6, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rwjblue commented Feb 6, 2015

quaertym commented Feb 7, 2015

jcope2013 commented Feb 7, 2015

ef4 commented Feb 7, 2015

mmun commented Feb 8, 2015

rwjblue commented Feb 8, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tim-evans commented Feb 9, 2015

rwjblue commented Feb 9, 2015

tim-evans commented Feb 9, 2015

rwjblue commented Feb 9, 2015

machty commented Feb 9, 2015

tim-evans commented Feb 9, 2015

kamal commented Mar 3, 2015

mixonic commented Mar 8, 2015