Lwc: internal stringifying mechanism for an array not picked up by reactive mechanism

[jbleyleSF]

Description

Array reference in template doesn't update when a new element is pushed to the array.

Steps to Reproduce

https://playground.lwcjs.org/projects/LvMY_tAT/2/edit

<template>
    <p>List: {list}</p>
    <p>ListToString: {listToString}</p>
    <button onclick={handleClick}>.push('foo')</button>
</template>

import { LightningElement, track } from 'lwc';

export default class App extends LightningElement {
   @track
   list = ['bar'];

    get listToString() {
        return this.list.join(', ');
    }

    handleClick() {
        this.list.push('foo');
    }
}

Expected Results

{list} updates in template

Actual Results

{list} doesn't update in template

Possible Solution
@caridy says

This is a bug in reactivity, for some reason the internal stringifying mechanism for an array is not picked up by the reactive mechanism.

Additional context/Screenshots
https://github.com/salesforce/lwc-docs/issues/100

[git2gus[bot]]

This issue has been linked to a new work item: W-7133214

[pmdartus]

This is not a reactivity issue, as you can see the engine is notified when pushing a new item in the list.

This issue comes from the fact that the diffing algo does an equality check against the object (in this case list) instead of the object .toString() value to check if a text node value should be updated or not.

[caridy]

@pmdartus I had a chance to chat with @jodarove about this last week. I don't think we should fix this. Two main reasons:

• completeness: it is not only about text nodes, any attribute value.
• perf: it is going to slow down everyone.

I asked @jodarove to work on an RFC where we can decide what to do with this edge case, but as of now, I feel that we should not fix it, just document it.

[Templarian]

@caridy Thinking about this agin and wondering if there is a nice way to throw an error for non-primitive types being used in the template or would that check be too slow? What about just in developer mode and not production.

The documentation can explain that all inline variables should be a primitive.

[Templarian]

@jodarove Let me know if you want help writing up an initial RFC for this. I think there is few ways to handle this. But a dev build level error would probably be the most friendly.

It should be relatively safe to not worry about it as much in a production build as one going from a string to an object/array is not likely.

[caridy]

I'm up for a dev-time warning on this one. It can't be build time though, it must be runtime because computed values in templates can lead to such issue. Few notes for whoever decides to work on this:

• built-in elements are the easy one (and probably covers 90% of the cases).
• IIRC there are exceptions to the rule that any attribute used in a template on built-in elements will be set as an attribute (if we use props for some, the compiler should have them listed somewhere).
• custom elements always use props (but some of those props are implementing the global html properties), hard to determine what is what even at runtime.

[Templarian]

That would be perfect. Can probably use this issue to track that work and skip the RFC. 👍

This is a nice dev experience issue. 🥰

[saw]

what is "dev time"? I think my concern here is that silent errors become gacks, which means customer cases

[pmdartus]

I think what @caridy means by dev-time and when the Aura application is running in PRODDEBUG mode. I don't think we should report an error here in this case that would cause a gack but rather log a warning message.

[jbleyleSF]

Please let me know when I need to update the docs.

[Templarian]

@jbleyleSF Assuming a warning message can be logged in this scenario we would want to mention somewhere in the template docs for users not to use variables in templates that are not primitives.

Same would hold true without this warning. So it could probably be documented prior to a PR/poc for this issue.

[caridy]

users not to use variables in templates that are not primitives.

@Templarian what does this mean?

[Templarian]

users not to use variables in templates that are not primitives.

@Templarian what does this mean?

Oops, that was worded badly. Variables not used for attributes and display purpose should be primitives. We might have a term for non-attribute variables. <span>{foo}</span>.

[caridy]

Hmm, I'm still confused why are you talking about the template here, the controls are at the JS file, the template should not dictate much, other than just usage.

[Templarian]

The main issue I was trying to address was related to <span>{arr}</span> usage with arrays not updating their displayed value in a template as expected. I think I'm now confused how this wouldn't relate to a template file. That's what this warning would be for.

[jbleyleSF]

Should I add guidance in the docs that properties used in templates must be primitive values, except when used in a for:each or iterator directive?

[caridy]

I will not say must, but should maybe :)