Skip to content
This repository has been archived by the owner on Mar 5, 2018. It is now read-only.

nested each causes endless rerender #43

Closed
MartinMalinda opened this issue Mar 31, 2017 · 13 comments
Closed

nested each causes endless rerender #43

MartinMalinda opened this issue Mar 31, 2017 · 13 comments

Comments

@MartinMalinda
Copy link

MartinMalinda commented Mar 31, 2017

If I have nested each helpers like so:

{{#each grid key="@index" as |gridRow|}}
  {{#each gridRow key="@index" as |gridItem|}}
    <grid-item />
  {{/each}}
{{/each}}

I can see endless re-renders in the timeline. Not sure if this is WAI.

Maybe it can happen with single each as well. (cc @GavinJoyce)

Simple reproduction repo is here: https://github.com/MartinMalinda/glimmer-endless-render

@GavinJoyce
Copy link
Contributor

GavinJoyce commented Mar 31, 2017

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
Copy link
Contributor

GavinJoyce commented Mar 31, 2017

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

@GavinJoyce
Copy link
Contributor

GavinJoyce commented Mar 31, 2017

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

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

@locks
Copy link
Contributor

locks commented Mar 31, 2017

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

@chadhietala
Copy link
Member

chadhietala commented Mar 31, 2017

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

@tomdale
Copy link
Contributor

tomdale commented Apr 9, 2017

@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
Copy link
Contributor

tomdale commented Apr 9, 2017

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

@CvX
Copy link

CvX commented Apr 10, 2017

@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
Copy link

@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
Copy link

CvX commented Apr 10, 2017

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

@balinterdi
Copy link

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

@CvX
Copy link

CvX commented Apr 10, 2017

@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
Copy link
Contributor

locks commented Mar 5, 2018

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!

@locks locks closed this as completed Mar 5, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants