useTransition "update" prop applies when order is unchanged

[Andarist]

https://codesandbox.io/s/q9n0lzmoq

Basically if have a list of [A] and we rerender without reordering, removing or deleting items such A item gets marked as updating - thus triggering the update transition. It's not a desirable effect though.

Fixing this is kinda tricky, because it's hard to cover all cases automatically without knowing the layout constraints 🤔

[drcmda]

Updates are normally all items that don't enter or leave. There's an update lifecycle that adds 100 to height, so 200something. What would you expect it to do?

[Andarist]

the expected result here would be that if the list stays the same between renders no transition should happen, most notably if that list has pending transitions they shouldnt be overriden by the update transition

[drcmda]

When do you expect update to kick in? The pending animation thing makes sense to me but there it gets hard for me to even say what should take precedence. The current ruleset is that updates are allowed to cut into ongoing animations, but the ongoing animations values should be merged, so we don't loose values. If enter animates color:blue, and update left:100, it should do both.

[Andarist]

When do you expect update to kick in?

Do you mean react update or spring update?

The current ruleset is that updates are allowed to cut into ongoing animations, but the ongoing animations values should be merged, so we don't loose values.

This makes complete sense to me - if the change is detected, the merging principal is great - the animation should preserve its state and aim to land in the merged state, unless we override a particular value.

Sorry that I can't prepare a react-spring specific demo right now, I'm short on time - but this demo based on react-pose can demonstrate the issue quite nicely - https://codesandbox.io/s/l48wl5jno9 . It just has different animation config for both enter & update states and it suffers from the same issue as useTransition hook - it marks the item as updating when the owning component receives unrelated update (and thus render gets called and hook gets recalculated).

[drcmda]

that's the general problem with using props as update trigger. for the other hooks we have

const [props, set, cancel] = useXXX(() => config)

that makes the config immutable and impervious to parental updates. but it isn't implemented for transition right now. would it solve the issue?

[Andarist]

Maybe - more imperative API would certainly give bigger control but would lose the ease of use. Not sure what's the ideal thing to do here - I've kinda only wanted to start a discussion around this to see if you have any ideas how this could be solved.

[drcmda]

yeah, that's we we offer both in most cases. it is very useful for events and often updating triggers, because it doesn't cause a render. but if you just have plain, seldom changing props, calling set feels like overhead.

[aleclarson]

The update prop is for updating animations on re-render, and it shouldn't be changed. We could add a reorder prop, which updates the animations of any item with a new index, but it doesn't seem like something many people are asking for.

[JasCodes]

@aleclarson Well you got one now..

[elstob]

@aleclarson I would also like to ask for it! This would allow for a lot more control over when elements should be animated.

[Nizarius]

@aleclarson i thought update prop triggers only on updating the array passed to it.
It seems obvious that even if you don't change order of items but create new array (like newArray = [...oldArray]) it should be triggered as newArray !== [...oldArray]. But it triggers on every re-render (even array prop is still the same).

Can we make lifecycle that triggers only on updating array and not for all re-renders of functional component?