Sanjibukai

Prevent LiveView from mounting when using the browser back button

Hello everybody,

I’m not sure if the title is clear but here is my problem:
I have different “pages” handled within the same LiveView (so it’s a LiveNavigation).
At one moment I have a form for which I save (or update) the changeset in the socket upon every input blur.

So that when I go back and forth on the pages, when I reach back to the form, every changes is still there.
Unless if I reach the first page!

Let me explain with a simplified picture:

In the example above the form is in “page 3”, but it might be anywhere..

So once I reached the form on Page 3, I can go back and forth to Page 2 and Page 4 (going back using the browser back button - going forth, either using the browser next button or the custom live_patch next buttons - both work fine), the form changes will always be there.

However as soon as I reach back to the Page 1 (still using the browser back button), when I go back to the form everything is lost.

It appears that every time I’m reaching Page 1, the LiveView is mounted again, so all the assigns are gone.

Now, a little trick could be to use (as shown above) a custom Go Back button which will go back to the “Home” with a live navigation.
This works because in that case what’s really happening is not a come back to the previous page in the browser history, but it’s a new page in the history that is on the previous page..
But even in this scenario, if at one moment I reach back the initial Page 1, everything is gone again.

I precise that this happen even when I’m coming in Page 1 from another LiveView (I mean when the Page 1 here is not the initial browser HTTP loaded page).

So, is this the normal behavior of LiveView?
If so, how to explain that?

And what I’m interested with, is there a way to prevent that?

I tried to push_patch on mount to the page itself (using a custom handled flag in order to prevent a redirection loop), but this is not working..

A solution might be to save the changes to the database and fetch them again, but in that process the data will only be partial and not yet valid, and I don’t want to deal with partial changesets etc. And with this database approach I think I’m losing the whole purpose of why I’m using LiveView in the first place..

Thanks for taking the time..

11 comments

/phoenix #liveview #history #mount #live_navigation

13 2679 11

2020-09-30 22:43:00 UTC

Most Liked

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

Yeah we ran into stuff like this with our live view pages. Basically, the solution is to always have the full state of the form in the actual web page. You can’t use the liveview process as the canonical store for anything.

Here is another scenario that can cause issues: Suppose someone is half way through the form, and you do a deploy. Boom, all their stuff is lost.

So basically, if you want to do a multi page form like this, what I recommend is storing any form values that have been submitted on previous pages in hidden attributes on the following page. Then, should live view need to reconnect the form recovery mechanism will be able to handle all the values. Related to this you can also experiment with the replace: true option on push patch.

Finally, If you want the form state to survive no matter where you go on the site, you can also experiment with a JS Hook that stores all of the form data in local storage.

Post #2

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

To me multi-node isn’t about bottlenecks, it’s about reliability and durability. Nodes go down, whether from issues with the underlying server or from an OOM bug or any number of reasons, and if you have multiple nodes up then your load balancer health checks can react and keep routing traffic to good nodes while your bad ones come back online or are replaced. If you only have one live node then when it goes down your system is simply down until you get it fixed.

This is why I think for this particular problem at least, the client side is the right place to store this info.

Post #8

chouzar

Hello @Sanjibukai, I’m unsure about the mount behaviour you are experiencing (since I don’t alter my path when moving between forms); but regarding persistence I currently leverage most form data to CubDB.

A couple of things to consider:

I have a main map/struct for the whole form to store the form state. It is validated, updated and stored in CubDB semi-regularly with each form change or submit event.
I have a token which is written to the url (part of the path or a querystring) and is used to retrieve the form state from the store.
You will probably need some security mechanism for token retrieval, to protect sensible data.
Also a mechanism to clean-up “forgotten” form fillups.

It has worked really well so far, but it took me some time to figure out the security aspect of tokens, the Cloak library helped a lot here.

@benwilson512 local storage recommendation sounds like a wonderful alternative.

Post #5