nested each causes endless rerender

[glimmerjs]

nested each causes endless rerender

[GavinJoyce]

This happens for me with a single {{#each}} too:

import Component from "@glimmer/component";

export default class MyApp extends Component {
  speakers = ['Tom', 'Yehuda', 'Ed'];
}

<ul>
  {{#each speakers key="@index" as |speaker|}}
    <li>{{speaker}}</li>
  {{/each}}
</ul>

"@glimmer/application": "^0.4.0",
"@glimmer/application-pipeline": "^0.5.2",
"@glimmer/component": "^0.3.8",
"@glimmer/resolver": "^0.3.0",

[GavinJoyce]

It seems that component.args = bucket.namedArgsSnapshot(); results in a propertyDidChange for args, which then causes a subsequent rerender. args are tracked here.

[GavinJoyce]

Related, we seem to rerender twice at boot time for an app with static content:

{{!-- template.hbs --}}
<div>
  hello
</div>

[locks]

@chadhietala I believe you were looking into some of this?

[chadhietala]

@tomdale this is what I was talking about. We need to check the global revision before we schedule a re-render.

[tomdale]

@chadhietala Nope. Args is a watched property, so setting it is causing it to rerender. It also means the current revision is getting bumped. As we talked about. 😉

[tomdale]

This is a weird case because we want args to invalidate other tracked properties, but not schedule a rerender.

[CvX]

@tomdale Is there anything that has to be done beyond removing args tracking?
I did that and added a test for the rerender loop (CvX/glimmer-component@13456a9).
All tests pass, but maybe there are some other args-related functionalities that were never tested?
I'd really like to squash this bug. 😃

[balinterdi]

@tomdale To clarify, we currently have to do @tracked('args') as we cannot track individual attributes, like @tracked('args.rating'), right? (I tried that and it didn't work but perhaps I was missing something?)

[CvX]

@balinterdi You're completely right, forgot about that use case.
Updated the test and added dirtying the args tag. CvX/glimmer-component@a8aaa2b

[balinterdi]

@CvX Does it work now? It's still a workaround, though, isn't it? (And we should be able to track individual properties.)

[CvX]

@balinterdi it does its job, but whether it should land on master in this form is a question for someone with more (ie. any 😁) experience with glimmer code.

Don't know what's the plan for tracking individual properties.

[locks]

This repo has been merged with glimmerjs/glimmer.js (into a monorepo setup). I am not sure if this issue is still applicable, but if you could confirm it is still an ongoing concern and open it over there that would be very helpful.

Sorry for the noise, but thank you for your help!