Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved backtracking re-render assertion message #14723

Merged
merged 1 commit into from
Jan 6, 2017

Conversation

GavinJoyce
Copy link
Member

@GavinJoyce GavinJoyce commented Dec 15, 2016

Closes #14709

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 GavinJoyce force-pushed the gj/better-backtracking-assertion branch from b7a210e to 1e845d5 Compare December 16, 2016 15:30
@GavinJoyce GavinJoyce force-pushed the gj/better-backtracking-assertion branch 2 times, most recently from 15fe368 to d2a0e91 Compare December 17, 2016 15:54
@GavinJoyce GavinJoyce changed the title [wip] better backtracking re-render assertion better backtracking re-render assertion Dec 17, 2016
@@ -107,8 +108,9 @@ export function Meta(obj, parentMeta) {

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
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the _ prefixes as they seemed incorrect

@@ -67,7 +67,8 @@ const IS_PROXY = 1 << 4;
if (isEnabled('ember-glimmer-detect-backtracking-rerender') ||
isEnabled('ember-glimmer-allow-backtracking-rerender')) {
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
Copy link
Member Author

@GavinJoyce GavinJoyce Dec 17, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 GavinJoyce force-pushed the gj/better-backtracking-assertion branch from d2a0e91 to dd472d7 Compare December 17, 2016 16:00
@GavinJoyce GavinJoyce changed the title better backtracking re-render assertion [WIP] better backtracking re-render assertion Dec 17, 2016
@GavinJoyce GavinJoyce force-pushed the gj/better-backtracking-assertion branch from cad7f6a to 9993a34 Compare December 17, 2016 16:43
@GavinJoyce GavinJoyce changed the title [WIP] better backtracking re-render assertion better backtracking re-render assertion Dec 17, 2016
@GavinJoyce GavinJoyce force-pushed the gj/better-backtracking-assertion branch from 9993a34 to 797d92f Compare December 17, 2016 17:06
@GavinJoyce
Copy link
Member Author

this is ready for review (/cc @chancancode)

@chancancode
Copy link
Member

chancancode commented Dec 18, 2016

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 GavinJoyce changed the title better backtracking re-render assertion [WIP] better backtracking re-render assertion Dec 18, 2016
@GavinJoyce
Copy link
Member Author

GavinJoyce commented Dec 18, 2016

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
Copy link
Member Author

GavinJoyce commented Dec 18, 2016

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

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

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

@GavinJoyce GavinJoyce force-pushed the gj/better-backtracking-assertion branch from c982807 to 83aa469 Compare December 23, 2016 19:24
@GavinJoyce GavinJoyce changed the title [wip] better backtracking re-render assertion better backtracking re-render assertion Dec 23, 2016
@GavinJoyce GavinJoyce force-pushed the gj/better-backtracking-assertion branch 2 times, most recently from 6d3c5c2 to 391bc85 Compare December 23, 2016 19:38
@GavinJoyce GavinJoyce changed the title better backtracking re-render assertion Improved backtracking re-render assertion message Dec 23, 2016
@GavinJoyce
Copy link
Member Author

GavinJoyce commented Dec 23, 2016

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

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

@GavinJoyce
Copy link
Member Author

GavinJoyce commented Jan 3, 2017

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

screen shot 2017-01-03 at 09 56 21

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

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

GavinJoyce commented Jan 5, 2017

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

@rwjblue
Copy link
Member

rwjblue commented Jan 5, 2017

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

Copy link
Member

@rwjblue rwjblue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 🚢...

@@ -74,6 +74,8 @@ class MountManager {
}

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

@@ -180,6 +180,8 @@ class OutletComponentManager {
}

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@@ -212,10 +216,19 @@ class OutletComponentManager {
didUpdate(state) {}
}

runInDebug(() => {
OutletComponentManager.prototype._pushToDebugStack = function(definition, environment) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@@ -203,6 +218,10 @@ class NonSingletonRenderManager extends AbstractRenderManager {
controller.set('model', args.positional.at(0).value());
}

didRenderLayout() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

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"/;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member Author

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

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

@rwjblue this is ready to go now I believe

Copy link
Member

@rwjblue rwjblue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@rwjblue rwjblue merged commit 44188c6 into emberjs:master Jan 6, 2017
@GavinJoyce GavinJoyce deleted the gj/better-backtracking-assertion branch January 6, 2017 23:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Improve "Backtracking re-render" assertion
5 participants