Improved backtracking re-render assertion message by GavinJoyce · Pull Request #14723 · emberjs/ember.js

GavinJoyce · 2016-12-15T20:40:49Z

This improves the backtracking re-render assertion message.

Before:

You modified message.message_goal.description twice on <(subclass of Ember.Model):ember3486> in a single render. This was unreliable and slow in Ember 1.x and is no longer supported. See #13948 for more details.

After:

You modified message.message_goal.description twice on <(subclass of Ember.Model):ember3486> in a single render. It was rendered in component:message-edit-expanding-container-component and modified in component:rules/predicate-date-value-component. This was unreliable and slow in Ember 1.x and is no longer supported. See #13948 for more details.

Feedback TODOs:

GavinJoyce · 2016-12-17T15:55:59Z

packages/ember-metal/lib/meta.js

  if (isEnabled('ember-glimmer-detect-backtracking-rerender') ||
      isEnabled('ember-glimmer-allow-backtracking-rerender')) {
-    this._lastRendered = undefined;
-    this._lastRenderedFrom = undefined; // FIXME: not used in production, remove me from prod builds


I removed the _ prefixes as they seemed incorrect

GavinJoyce · 2016-12-17T15:57:02Z

packages/ember-metal/lib/meta.js

  members.lastRendered = ownMap;
-  members.lastRenderedFrom = ownMap; // FIXME: not used in production, remove me from prod builds
+  members.lastRenderedReferenceMap = ownMap; // FIXME: not used in production, remove me from prod builds
+  members.lastRenderedTemplateMap = ownMap; // FIXME: not used in production, remove me from prod builds


runInDebug doesn't seem to work here. I'd be grateful for any tips on how I can avoid setting these in production builds

GavinJoyce · 2016-12-17T17:32:49Z

this is ready for review (/cc @chancancode)

chancancode · 2016-12-18T01:08:19Z

Looks great! 👍

I think there are some issues with the meta-metaprogramming usage. For example I believe the underscore was correct, and we could try to figure out the runInDebug stuff. I am currently travelling but I'm sure someone else (Robert, Kris, Edward, Stef etc) could help with those.

Another thing is we probably should be pushing something in all component managers (dynamic components, render helper, mount, etc) as those are all the places we switch templates.

I think we can improve the message a bit too. Maybe start with the problem summary (you modified X twice in the same render) then go into the details on the next sentence/line to make it more readable.

Other than those issues, this looks great!! Thanks for working on this.

Can you get some other commenters on the original thread (Stanley?) to try this out?

GavinJoyce · 2016-12-18T09:17:02Z

I think we can improve the message a bit too. Maybe start with the problem summary (you modified X twice in the same render) then go into the details on the next sentence/line to make it more readable.

updated message:

You modified message.message_goal.description twice on <(subclass of Ember.Model):ember3486> in a single render. It was rendered in component:message-edit-expanding-container-component and modified in component:rules/predicate-date-value-component. This was unreliable and slow in Ember 1.x and is no longer supported. See #13948 for more details.

GavinJoyce · 2016-12-18T13:12:19Z

I've cut a 2.10.2-with-improved-backtracking-assertion build and invited people to try it out in their apps: #13948 (comment)

If you'd like to try it out yourself, you can here: GavinJoyce/backtracking#10

scottmessinger · 2016-12-19T17:25:11Z

@GavinJoyce I love the error message. The "rendered in" and "modified in" parts will be super helpful.

GavinJoyce · 2016-12-23T20:06:16Z

This is ready for review (/cc @chancancode).

Here's a collection of improved backtracking re-render errors from this build : GavinJoyce/backtracking#10

GavinJoyce · 2017-01-03T09:58:28Z

I just noticed an issue in my own app, the debug stack seems to be missing a pop somewhere:

UPDATE: we're not popping in CurlyComponentManager.prototype.didUpdateLayout so the stack grows incorrectly on component updates

GavinJoyce · 2017-01-05T11:55:55Z

^ That's been addressed. This is ready for review again

rwjblue · 2017-01-05T20:54:03Z

I think this is good to go, would love for a review by @wycats / @chancancode / @krisselden / @chadhietala for sanity check...

rwjblue

This looks great! @tomdale and I did a "pair review" session to review this, and came up with a few small tweaks/suggestions.

I think after those are taken care of this is ready to 🚢...

rwjblue · 2017-01-06T16:21:32Z

packages/ember-glimmer/lib/syntax/mount.js

  }

  create(environment, { name, env }, args, dynamicScope) {
+    runInDebug(() => this._pushToDebugStack(name, env));


Should this be pushing with engine:${name} instead of just name? The other usages that I see above are all using "factory full name" semantics...

rwjblue · 2017-01-06T16:28:57Z

packages/ember-glimmer/lib/syntax/outlet.js

  }

  create(environment, definition, args, dynamicScope) {
+    runInDebug(() => this._pushToDebugStack(definition, environment));


What is definition here? As mentioned above, most of the names in the debug stack are representing "factory full names", but I am not sure what this one is actually going to add.

After reading below in the _pushToDebugStack method for OutletManager we are grabbing definition.template.meta.moduleName. I think we should change things around so that we are pushing like:

runInDebug(() => this._pushToDebugStack(`template:${definition.template.meta.moduleName}`, environment));

Then eventually we can make a shared base class so that each _pushToDebugStack implementation does not have to be unique.

rwjblue · 2017-01-06T16:29:43Z

packages/ember-glimmer/lib/syntax/outlet.js

 }

+runInDebug(() => {
+  OutletComponentManager.prototype._pushToDebugStack = function(definition, environment) {


Commented above, but I think ideally all of the _pushToDebugStack implementations should basically be the same (and either in this PR or in a future refactor be changed to extend from a common base class to avoid duplication).

Thanks, I'll follow up in a subsequent PR and refactor away the duplicate _pushToDebugStacks

rwjblue · 2017-01-06T16:34:05Z

packages/ember-glimmer/lib/syntax/render.js

    controller.set('model', args.positional.at(0).value());
  }

+  didRenderLayout() {


Since this wasn't previously defined, you could probably define this in the AbstractRenderManager above (and not have to define it for each of SingletonRenderManager and NonSingletonRenderManager).

We should also only add didRenderLayout (for debug purposes) when running in a debug build (in production builds at the moment the current code would result in an empty function).

rwjblue · 2017-01-06T16:43:20Z

packages/ember-glimmer/tests/integration/application/rendering-test.js

+      template: 'Hi {{person.name}} from component'
+    });
+
+    let expectedBacktrackingMessage = /modified "model\.name" twice on \[object Object\] in a single render\. It was rendered in "routeWithError" and modified in "component:x-foo"/;


This is slightly ambiguous still (e.g. "what is routeWithError, is it the controller or the template?").

Given the suggested changes in an earlier comment, this would become template:routeWithError which should remove the ambiguity.

GavinJoyce · 2017-01-06T17:32:21Z

@rwjblue @tomdale thanks for the great feedback, I'll make the suggested changes soon

GavinJoyce · 2017-01-06T21:41:58Z

@rwjblue this is ready to go now I believe

rwjblue

Awesome, thank you so much for working on this @GavinJoyce!

GavinJoyce force-pushed the gj/better-backtracking-assertion branch from b7a210e to 1e845d5 Compare December 16, 2016 15:30

This was referenced Dec 16, 2016

2.10.1-intercom intercom/ember#6

Open

2.10.1 intercom with backtracking intercom/ember#7

Open

Improve "Backtracking re-render" assertion #14709

Closed

GavinJoyce force-pushed the gj/better-backtracking-assertion branch 2 times, most recently from 15fe368 to d2a0e91 Compare December 17, 2016 15:54

GavinJoyce changed the title ~~[wip] better backtracking re-render assertion~~ better backtracking re-render assertion Dec 17, 2016

GavinJoyce commented Dec 17, 2016

View reviewed changes

GavinJoyce force-pushed the gj/better-backtracking-assertion branch from d2a0e91 to dd472d7 Compare December 17, 2016 16:00

GavinJoyce changed the title ~~better backtracking re-render assertion~~ [WIP] better backtracking re-render assertion Dec 17, 2016

GavinJoyce force-pushed the gj/better-backtracking-assertion branch from cad7f6a to 9993a34 Compare December 17, 2016 16:43

GavinJoyce changed the title ~~[WIP] better backtracking re-render assertion~~ better backtracking re-render assertion Dec 17, 2016

GavinJoyce force-pushed the gj/better-backtracking-assertion branch from 9993a34 to 797d92f Compare December 17, 2016 17:06

GavinJoyce changed the title ~~better backtracking re-render assertion~~ [WIP] better backtracking re-render assertion Dec 18, 2016

GavinJoyce mentioned this pull request Dec 18, 2016

runInDebug isn't available in meta.js module initialization #14732

Closed

GavinJoyce added a commit to intercom/ember that referenced this pull request Dec 18, 2016

built from emberjs/ember.js#14723

0a29261

This was referenced Dec 18, 2016

built from https://github.com/emberjs/ember.js/pull/14723 intercom/ember#8

Open

trying out 2.11.0-canary-with-improved-backtracking-assertion GavinJoyce/backtracking#7

Open

[Glimmer 2] "Backtracking re-render" is now an assertion #13948

Closed

GavinJoyce force-pushed the gj/better-backtracking-assertion branch from 8c5b6e1 to 825c67d Compare December 19, 2016 09:23

GavinJoyce force-pushed the gj/better-backtracking-assertion branch 2 times, most recently from 7f49d40 to a80c995 Compare December 20, 2016 09:14

This was referenced Dec 20, 2016

2.10.2-with-improved-backtracking-assertion-and-backtracking intercom/ember#11

Open

2.10.2-with-improved-backtracking-assertion intercom/ember#10

Open

GavinJoyce force-pushed the gj/better-backtracking-assertion branch from c982807 to 83aa469 Compare December 23, 2016 19:24

GavinJoyce changed the title ~~[wip] better backtracking re-render assertion~~ better backtracking re-render assertion Dec 23, 2016

GavinJoyce force-pushed the gj/better-backtracking-assertion branch 2 times, most recently from 6d3c5c2 to 391bc85 Compare December 23, 2016 19:38

GavinJoyce changed the title ~~better backtracking re-render assertion~~ Improved backtracking re-render assertion message Dec 23, 2016

GavinJoyce force-pushed the gj/better-backtracking-assertion branch 4 times, most recently from 8922c86 to f599dda Compare January 5, 2017 11:37

locks requested review from chadhietala, chancancode, krisselden, tomdale and wycats January 6, 2017 10:03

rwjblue requested changes Jan 6, 2017

View reviewed changes

tomdale approved these changes Jan 6, 2017

View reviewed changes

GavinJoyce force-pushed the gj/better-backtracking-assertion branch 2 times, most recently from 117e2f3 to d626276 Compare January 6, 2017 20:50

[BUGFIX beta] better backtracking re-render assertion

cd11371

GavinJoyce force-pushed the gj/better-backtracking-assertion branch from d626276 to cd11371 Compare January 6, 2017 20:56

rwjblue approved these changes Jan 6, 2017

View reviewed changes

rwjblue merged commit 44188c6 into emberjs:master Jan 6, 2017

GavinJoyce deleted the gj/better-backtracking-assertion branch January 6, 2017 23:26

GavinJoyce mentioned this pull request Jan 7, 2017

Refactor duplicate _pushToDebugStack methods #14800

Merged

Uh oh!

Conversation

GavinJoyce commented Dec 15, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GavinJoyce Dec 17, 2016

Choose a reason for hiding this comment

Uh oh!

GavinJoyce Dec 17, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GavinJoyce commented Dec 17, 2016

Uh oh!

chancancode commented Dec 18, 2016 • edited by wycats Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GavinJoyce commented Dec 18, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GavinJoyce commented Dec 18, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

scottmessinger commented Dec 19, 2016

Uh oh!

GavinJoyce commented Dec 23, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GavinJoyce commented Jan 3, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GavinJoyce commented Jan 5, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rwjblue commented Jan 5, 2017

Uh oh!

rwjblue left a comment

Choose a reason for hiding this comment

Uh oh!

rwjblue Jan 6, 2017

Choose a reason for hiding this comment

Uh oh!

rwjblue Jan 6, 2017

Choose a reason for hiding this comment

Uh oh!

rwjblue Jan 6, 2017

Choose a reason for hiding this comment

Uh oh!

GavinJoyce Jan 6, 2017

Choose a reason for hiding this comment

Uh oh!

rwjblue Jan 6, 2017

Choose a reason for hiding this comment

Uh oh!

rwjblue Jan 6, 2017

Choose a reason for hiding this comment

Uh oh!

GavinJoyce commented Jan 6, 2017

Uh oh!

GavinJoyce commented Jan 6, 2017

Uh oh!

rwjblue left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

GavinJoyce commented Dec 15, 2016 •

edited

Loading

GavinJoyce Dec 17, 2016 •

edited

Loading

chancancode commented Dec 18, 2016 •

edited by wycats

Loading

GavinJoyce commented Dec 18, 2016 •

edited

Loading

GavinJoyce commented Dec 18, 2016 •

edited

Loading

GavinJoyce commented Dec 23, 2016 •

edited

Loading

GavinJoyce commented Jan 3, 2017 •

edited

Loading

GavinJoyce commented Jan 5, 2017 •

edited

Loading