There's a few remaining issues with restoring history if locks were applied. As a result, currently it's safer to ensure locks are removed before refreshing. Recovering from these issues if they occur can be challenging and sometimes impossible.
Locks not always restored at right index
With the way history is currently replayed, it's possible for some states to fail being created, causing a different history length.
This results in locks being restored at the wrong index, which in turn seems to not be very well handled and can result in crashes.
When "chopping off" future by doing a new action in the past, if some state was locked in this future, AND the state is reducer based, AND the "chopped off" future contains more actions before the locked entry, all actions except the locked one are lost when refreshing
While there's quite a few conditions for this to occur, it breaks a use case: it's nice to be able to clean up history while preserving your relevant changes.
Scroll restoration can fire too late, causing it to destroy the most recent history entry
This is due to using scrollIntoView with smooth scrolling. This causes scroll to be tracked during this animation. If you then navigate back in history while this is still firing, it will create a new state with only the scroll position, displacing whatever was the latest entry.
There's a few remaining issues with restoring history if locks were applied. As a result, currently it's safer to ensure locks are removed before refreshing. Recovering from these issues if they occur can be challenging and sometimes impossible.
Locks not always restored at right index
With the way history is currently replayed, it's possible for some states to fail being created, causing a different history length.
This results in locks being restored at the wrong index, which in turn seems to not be very well handled and can result in crashes.
When "chopping off" future by doing a new action in the past, if some state was locked in this future, AND the state is reducer based, AND the "chopped off" future contains more actions before the locked entry, all actions except the locked one are lost when refreshing
While there's quite a few conditions for this to occur, it breaks a use case: it's nice to be able to clean up history while preserving your relevant changes.
Scroll restoration can fire too late, causing it to destroy the most recent history entry
This is due to using
scrollIntoViewwith smooth scrolling. This causes scroll to be tracked during this animation. If you then navigate back in history while this is still firing, it will create a new state with only the scroll position, displacing whatever was the latest entry.