replaceRootHistory sets the initial type to "patch". Now assuming the following events:
initial navigation to /page1
History:
==> /page1, type patch
Navigating to /page2 (navigate, no patch)
/page1, type patch
==> /page2, type redirect
Then we'd call replaceRootHistory after the new join:
/page1, type patch
==> /page2, type patch
If we now use the back button, the browser would send us a popstate event including the previous state (type=patch). Instead of a navigate, we'd do a patch.
We could change replaceRootHistory to not assume type=patch, but then the initial PR would be useless as well, as there would still be a remount when navigating back.
To properly fix this, we'd need a way to get the state from before the popstate event to determine what navigation type was used, but that's not possible. Another option would be to always update the current state before pushing a new one to include a backType that would be used when navigating in the other direction. But this would require us to be able to distinguish a back from a forward navigation, as we'd only want to use the backType when navigating back. There are ways to do this (https://stackoverflow.com/questions/8980255/how-do-i-retrieve-if-the-popstate-event-comes-from-back-or-forward-actions-with), but it's definitely not pretty and doesn't seem worth it imho.
We might revisit this in the future, when the Navigation API is more widely available.
Reverts phoenixframework/phoenix_live_view#3335 Fixes https://github.com/phoenixframework/phoenix_live_view/issues/3508.
The history API is the worst...
replaceRootHistory sets the initial type to "patch". Now assuming the following events:
History:
Then we'd call replaceRootHistory after the new join:
If we now use the back button, the browser would send us a popstate event including the previous state (type=patch). Instead of a navigate, we'd do a patch.
We could change replaceRootHistory to not assume type=patch, but then the initial PR would be useless as well, as there would still be a remount when navigating back.
To properly fix this, we'd need a way to get the state from before the popstate event to determine what navigation type was used, but that's not possible. Another option would be to always update the current state before pushing a new one to include a
backTypethat would be used when navigating in the other direction. But this would require us to be able to distinguish a back from a forward navigation, as we'd only want to use thebackTypewhen navigating back. There are ways to do this (https://stackoverflow.com/questions/8980255/how-do-i-retrieve-if-the-popstate-event-comes-from-back-or-forward-actions-with), but it's definitely not pretty and doesn't seem worth it imho.We might revisit this in the future, when the Navigation API is more widely available.