Push_patch/live_patch behavior

Hey there,
I am currently playing around with some LV and stumbled on a behavior I don’t really understand/want to discuss.
I have a simple live route that implements steps which are rendered as LiveComponents.

When clicking “Next” I send a message from the child component to its parent, the parent then triggers a push_patch to the next step. This way the user could switch between steps using browser navigation.

So far so good, now whats odd about this:
Navigating through the steps via “Next”-button triggers handle_params/3 instead of mount/3 as expected.

Let’s say I am in step 3/5: when navigating through browser history back and forth handle_params/3 is called. Except if I am hitting step 1/5 which is also the users entrypoint, in this case mount/3 is called. At this point one could argue that this is expected behavior.
Now I am navigating forth again (browser), from 1 to 2 to 3 and this time mount is called in every step. This is were I am not quite sure if this behavior is something that is intended.

You can find the generic example here:

live_patch works how it’s supposed to work. Update the current liveview process with another url. mount/3 is only called when a liveview process is started up, handle_params/3 each time the url changes. Navigating using the browser history is like calling live_redirect, which not only changes the url, but also remounts the liveview process (even if it’s the same one). The same would happen e.g. if your client lost connection for a moment.

1 Like

Navigating using the browser history is like calling live_redirect , which not only changes the url, but also remounts the liveview process (even if it’s the same one).

As I described, the LV is not remounted, when navigating through the browser history as long as I don’t hit the users entrypoint. What you described would result in calling mount every time someone is navigating through browser history or am I getting this wrong?

That’s because step 1/5 was added to the browser as a regular navigation. Once this history entry is popped, there is no LV information. So we need to do a mount. But once we mount, we end-up reloading the current LiveView, which means we can no longer use handle_params for the next steps because the LiveView ID in the browser history no longer matches the one on the page.

We discussed changing the current history once the LV is loaded, so it also works for step 1/5, but there were some (or many?) issues in cross browser support.

In a nutshell, we keep live patching while we can, but once we cannot, we start live redirecting.

1 Like

Thanks for your answer. The sad thing about this, is that e.g. a multi-step formular would lose its state (if not persited in another way) when the user hits the first step again.

And that is exaclty what I was afraid of to hear.