Prevent LiveView from mounting when using the browser back button

[Sanjibukai]

Hi @benwilson512 ,

@benwilson512

Related to this you can also experiment with the replace: true option on push patch.

Indeed I already tried this option. And to be honest, it wasn’t clear enough for me in the docs Live navigation — Phoenix LiveView v1.2.5) to what is the exact behavior with and without.. I figured it out by making some tests.

@benwilson512

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.

This is an interesting option..
I think that this is the way I’ll go.
Thank you!
Do you have some readings (or doc links) to propose regarding this?
I think that it involves the session, right?

---

But just some thoughts about this solution..

In fact this can also solve another problem I encountered.
Passing assigns between LiveViews.

At first I naively thought that doing the following will end up passing the data:

# In a handle_event of one LiveView
  socket =
    socket
      |> assign(validated_email: email)
      |> push_redirect(to: "/home")

  {:noreply, socket}

# In the mount of another LiveView
def mount(_params, session, socket) do
  IO.puts(socket.assigns.validated_email) #ERROR - validated_email does not survive from previous LiveView
end

But it appears that (probably for good reasons) the assigns don’t survive from previous LiveViews..
Unless the flash!
Which I’m using to solve this problem.

---

@benwilson512

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.

For example, in my case I’m doing exactly this (a multi step form) but without even reaching to the database.
What I’m doing is everything in memory (still using changeset and using apply_changes if they are valid).
Since we have LiveView, I don’t think this is an anti-pattern.
Quite the opposite, I think that LiveView brought an interesting use-case.

If the user left the site (closing the page)..
I don’t care that when he come back all the data is lost.
This is also applicable if he hit the refresh button, or go to an arbitrary page of the process by typing the url in the browser.
Since it’s the intended usage.
In fact, currently I’m even doing this, I test for the presence of the data I’m concerned with in the flash..
If it’s not present then I push_redirect the user back to where he should have been in the beginning (ie. validating his email in this use case)

---

Regarding this subject, wouldn’t be a good solution, to provide some kind of “persisted” data in the context of the socket (like the assigns but persisted between LiveViews.)
Like the flash but persisted..
I mean the flash is able to be passed between LiveView but after each round-trip it’s reset.

I think that there is nothing blocking, right?

We can simply call it store!
And using the same singular/plural convention than assigns (and always returning back a socket), it can look like this..

# In a handle_event of one LiveView
  socket =
    socket
      |> store(validated_email: email)
      |> push_redirect(to: "/home")

  {:noreply, socket}

# In the mount of another LiveView
def mount(_params, session, socket) do
  IO.puts(socket.stores.validated_email) #Data available
end

We can even have some kind of API (as we have for assigns like assign and update) and maybe even add a pop that will remove a data.

Since we cannot use the session to write into, this might be a good solution.

I don’t think that this is an edge use-case of mine.

What do you think?