Showing is too volatile to live in ViewEnvironment
#844
Comments
rjrjr
added a commit
that referenced
this issue
Jul 28, 2022
Using the `ViewEnvironment` to hold the current `Screen` and `Overlay` was conceptually very clean, but was bad for performance in Compose, which would recompose too often when a new `ViewEnvironment` was not equal to the previous one -- all due to `Showing` being updated. We now store the canonical `Screen` rendering for each `View` in a tag, and the `Overlay` for each `Dialog` in a tag on its decorView. Fixes #844
rjrjr
added a commit
that referenced
this issue
Jul 28, 2022
Using the `ViewEnvironment` to hold the current `Screen` and `Overlay` was conceptually very clean, but was bad for performance in Compose, which would recompose too often when a new `ViewEnvironment` was not equal to the previous one -- all due to `Showing` being updated. We now store the canonical `Screen` rendering for each `View` in a tag, and the `Overlay` for each `Dialog` in a tag on its decorView. Fixes #844
rjrjr
added a commit
that referenced
this issue
Jul 28, 2022
Using the `ViewEnvironment` to hold the current `Screen` and `Overlay` was conceptually very clean, but was bad for performance in Compose, which would recompose too often when a new `ViewEnvironment` was not equal to the previous one -- all due to `Showing` being updated. We now store the canonical `Screen` rendering for each `View` in a tag, and the `Overlay` for each `Dialog` in a tag on its decorView. Fixes #844
rjrjr
added a commit
that referenced
this issue
Jul 28, 2022
Using the `ViewEnvironment` to hold the current `Screen` and `Overlay` was conceptually very clean, but was bad for performance in Compose, which would recompose too often when a new `ViewEnvironment` was not equal to the previous one -- all due to `Showing` being updated. We now store the canonical `Screen` rendering for each `View` in a tag, and the `Overlay` for each `Dialog` in a tag on its decorView. Fixes #844
rjrjr
added a commit
that referenced
this issue
Jul 28, 2022
Using the `ViewEnvironment` to hold the current `Screen` and `Overlay` was conceptually very clean, but was bad for performance in Compose, which would recompose too often when a new `ViewEnvironment` was not equal to the previous one -- all due to `Showing` being updated. We now store the canonical `Screen` rendering for each `View` in a tag, and the `Overlay` for each `Dialog` in a tag on its decorView. Fixes #844
rjrjr
added a commit
that referenced
this issue
Jul 29, 2022
Using the `ViewEnvironment` to hold the current `Screen` and `Overlay` was conceptually very clean, but was bad for performance in Compose, which would recompose too often when a new `ViewEnvironment` was not equal to the previous one -- all due to `Showing` being updated. We now store the canonical `Screen` rendering for each `View` in a tag, and the `Overlay` for each `Dialog` in a tag on its decorView. Fixes #844
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If
ViewEnvironment.equals()returns false on a call toWorkflowRendering(), unwanted recomposition happens.Showingis always updated to include the latest rendering, which is 99% likely to be unequal to its predecessor (new event handling lambdas). It's way too late to replace all the event handling lamdbas in the world with an event object based mechanism, so I think I need to find a new home forShowing. Back to a view tag?https://workflow-community.slack.com/archives/C013JGW58N7/p1658941768749279?thread_ts=1658939305.914679&cid=C013JGW58N7
The text was updated successfully, but these errors were encountered: