Description
Describe the problem
The problem that update_keyed_each
needs to solve seems really similar to the problem hydration
needs to solve, i.e. "How do we reorder nodes with the minimal number of operations possible?"
Describe the proposed solution
Maybe update_keyed_each
could also benefit from the longest increasing subsequence logic from the hydration pull request #6395. Maybe both subsystems could reuse the same code, potentially reducing the code size and increasing keyed-each performance.
I currently don't have a lot of free time so I thought this might be interesting for someone else willing to look into it.
Alternatives considered
I have not fully analyzed the current update_keyed_each
logic so it might be that it already does minimal operations given its requirements. In that case, I am sorry to have bothered you all :)
Importance
nice to have