Improve "Backtracking re-render" assertion

[GavinJoyce]

I've a few backtracking re-render issues to solve in my app and I'm interested in improving the assertions to make this easier for me and others. This issue will serve as a place to capture any discussion or progress.

The current assertion message for this example looks like:

Assertion Failed: You modified model.name twice on [object Object] in a single render. This was unreliable and slow in Ember 1.x and is no longer supported...

It would be nice to improve this to include more information on where the property was originally consumed as well as where it was then mutated. Something like this would be nice to aim for:

Assertion Failed. You rendered "model.name" in "templates/example1.hbs" and modified it in "components/component-that-changes-name-on-init" in a single render. This was unreliable and slow in Ember 1.x and is no longer supported...

Here are some thoughts from @chancancode on how we might do this.

https://embercommunity.slack.com/archives/dev-ember/p1481392322000438:

Useful links:

• ember-metal/lib/transaction.js
• every time we consume
• every time we set

[GavinJoyce]

For the You rendered "model.name" in "templates/example1.hbs" part, we should aim to include this data in meta when in debug mode so that we can use it when we detect a set on an already rendered property.

Looking at the available context where we currently set lastRenderedFrom[key], we don't appear to have easy access to anything that would allow us to identify the source template:

We have easy access to:

• the parent object and meta
• the reference
• the transaction context, which includes:

It's not immediately clear to me how we can get any source template details from this. Some ideas the I'm going to explore:

• Can we calculate the last DOM node rendered that has the reference? If so, we should be able to work out the containing view
• As we're rendering the template, and at a higher level that within the reference, can we store additional data in a new lastRenderedIn meta key?

[GavinJoyce]

https://embercommunity.slack.com/archives/dev-ember/p1481478414000479

[GavinJoyce]

We have a reference when setting lastRenderedFrom. We also have easy access to the transaction context:

Somewhere within the context, we have an opcode which also uses the same reference:

This gives us access to bounds which includes pointers into the DOM. We can then determine which view this DOM belongs to and use this for the better assertion message.

Possible next steps:

• how do we determine in the transaction context the last rendered opcode which uses the reference?
• will this work for other cases, eg. helpers and nested references
• can we map from DOM node to template identifier?

[chancancode]

@GavinJoyce another idea: we can potentially use CurlyComponentManager#create and CurlyComponentManager#didRenderLayout as a pair and keep a stack of "current component" (we currently use that for the component instrumentation, so I think it could work). So at least we can tell you which component's template was causing issues (i.e. that should have enough information to report "...user.foo was first read while reading component:user-profile and later modified while rendering component:another-thing).

Probably need to add more instrumentation hooks to Glimmer if we want to get more granular than that.

[GavinJoyce]

@chancancode thanks, I've created a quick spike (😷 using a global to track the last rendered component 😷) and it works pretty well in our app:

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:

Assertion Failed: You rendered message.message_goal.description in component:message-edit-expanding-container-component and modified it in component:rules/predicate-date-value-component (<(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.

Next Steps:

• can we also track route templates?
• tests + implementation: Improved backtracking re-render assertion message #14723

[kiwiupover]

Thanks heaps Mr Joyce. @GavinJoyce