You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Android-specific renderWorkflowIn function is a convenience function that minimizes the fuss required to get androidx to save and restore TreeSnapshot. Because it maps our usual StateFlow<RenderingAndSnapshot> to just StateFlow<RenderingT>, it will short circuit if the root rendering type implements equals() in a naive way -- like a data class does, say. (RenderingAndSnapshot has plain old default instance equality, so this is a non-issue in our core method.)
This is pretty surprising when it happens, and hard to debug if you're not aware of StateFlow's behavior. I don't think punching up the kdoc is a reasonable answer.
I'm wondering if we can find another way to be convenient, maybe by building that snapshot handling into WorkflowLayout itself.
I'd consider this a blocker to workflow UI leaving beta.
The text was updated successfully, but these errors were encountered:
The Android-specific
renderWorkflowIn
function is a convenience function that minimizes the fuss required to get androidx to save and restoreTreeSnapshot
. Because it maps our usualStateFlow<RenderingAndSnapshot>
to justStateFlow<RenderingT>
, it will short circuit if the root rendering type implementsequals()
in a naive way -- like adata class
does, say. (RenderingAndSnapshot
has plain old default instance equality, so this is a non-issue in our core method.)This is pretty surprising when it happens, and hard to debug if you're not aware of
StateFlow
's behavior. I don't think punching up the kdoc is a reasonable answer.I'm wondering if we can find another way to be convenient, maybe by building that snapshot handling into
WorkflowLayout
itself.I'd consider this a blocker to workflow UI leaving beta.
The text was updated successfully, but these errors were encountered: