Prevent LiveView from mounting when using the browser back button

[Sanjibukai]

@chouzar

I’m unsure about the mount behaviour you are experiencing (since I don’t alter my path when moving between forms);

Hello @chouzar
In fact the need to change the path is about to give some hint to the user (not really needed but it’s there). Also it gives for free, browser history navigation in some way..

@chouzar

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.

In some way I’m doing exactly the same, but in memory..
But do you still using Changesets?
I mean are you storing changesets data or just the bare params maps?

I tried to track the form state (which also span on multiple schemas - and this is in fact the rational for going down this route with mutlistep forms) with simply storing the form params as bare maps..

And simply use that whole map at the end and let the changesets do the work with validating.
But this works only if I don’t give feedback to the user, until the very last step..
Which is anyway unpractical, because in this case how to define in which form sent back the user to correct the inputs? The first one by default seems less than ideal.

Currently the solution I found was to encapsulate the former LiveViews as stateful LiveComponents inside a parent LiveView which has all the data in dedicated changesets in its assigns.

I’m not a fan of this solution since now I have to deal with events inside the LiveComponents and sending dedicated messages to the parent (using send on the LiveComponent and handle_info on the LiveView).
It’s not a big deal, but there’s some boilerplate to deal with.
But dealing with the forms changesets (data validation) is now dead simple..

@chouzar

You will probably need some security mechanism for token retrieval, to protect sensible data.

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.

I don’t get the security concerns related to tokens..
I mean the token will act like a key for you to retrieve in your KV store the data related to this token.
Or do you use the token itself as encrypted data?

@benwilson512

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

@chouzar

Definitely sounds like the simpler and right solution for transient “browser” data.

Yes I’m also thinking that.
At the end of the day, until the user validated the form, it’s like he’s still a “public” user and there’s no need to save any data that as @chouzar said will need to be cleaned up.

Also @benwilson512 (I’m still asking since you’re already dealing with this kind of stuff - I mean interaction from client side to server side)…
Do you have any resources to propose on how to interact with client-side storage within LiveView?
It would have been so easier if we could have write access to the session data.
But currently, I don’t really get how to do that.

Anyway thank you for your thoughts..