-
Notifications
You must be signed in to change notification settings - Fork 190
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
Is bug? is bugfix? :: affecting ember-source 5.6+ with false-negatives w/ backtracking re-render assertions #1629
Comments
@NullVoxPopuli this is as designed, you are reading and writing to a tracked property in one render pass. This makes it so that there are potentially 2 versions of the same tracked property. There isn't any way for it to know you are not using the prior version you read. There are also simple refactors to avoid it. Most of this is because you want a tracked property for local changes based on derived state. You can create a new instance with a tracked property and cache it to the source tracked. Like tracked url to derived class State tracked isLoading = true, cached on url ==. This lets you set isLoading to false when it finishes and if the url changes, the cache invalidates and you get a new State for the new url initialized to isLoading = true. |
This issue comes up because the old assertion was tied to a chain of state tied all the way into the rendering. As things move to tracked, rendering is basically cached on the source versions of tracked and doesn't book keep all the way to rendering. so the more systems that refactor to rely on autotracking the more you hit cases where people are reading during render and even if they aren't using that read value in any derived state, autotracking can't assume that. |
I think the reproductions I have are not reproductions, because they fail on 0.84.3 as well. |
I'm not sure I understand correctly what you're talking about here but could this also be what you're looking for as a reproduction? |
Reproduction in Limber (locally running on port 4301)
Notes:
@glimmer/*
packages from 0.84.3 to 0.85.13 emberjs/ember.js#20561Examples of real code that "broke" in ember 5.6+ (which, imo, is legit problematic, and should be migrated away from)
createRecord
as the result of a user action, such as submitting a form.localCopy
from tracked-toolbox if local state forking needing.for example:
Examples of real code that "broke" in ember 5.6+ which maybe shouldn't have
... trying to find reproductions ...
The text was updated successfully, but these errors were encountered: