Use Alpine.clone to avoid existing component being reset when navigating using the history. about alpine-turbo-drive-adapter HOT 7 CLOSED

Would you take a Pull Request for this?

from alpine-turbo-drive-adapter.

Yeah, sure. It may need some thinking and discussion though because it might not be the desired behavior.
For example, a sidebar menu, you click on something, a flag is set to true to show the menu then you click on a link to navigate away, when you navigate back you won't expect the sidebar to be open.
What do you think? Maybe we should cache them only if there is a specific attribute.

from alpine-turbo-drive-adapter.

I actually think in that case the state should be preserved on the back button in that case. I do worry about how it will work with removing Alpine generated DOM nodes.

from alpine-turbo-drive-adapter.

I'm not sure people would agree, if they hit back and a modal was already open, I think they would report it as a bug

from alpine-turbo-drive-adapter.

So, I've been using data-turbolinks-permanent to preserve client state across navigation, but I can see how the "back button" would semantically be different than clicking on a link ("get me back to my previous state.") In 99% of the cases I suspect that wold be the correct/expected behaviour, but don't think you could add something like this without a way of opting out of it.

from alpine-turbo-drive-adapter.

yeah, I'm not convinced because stuff like modals and submenus could open when you go back menu if you clicked on a link inside them which feels a bit weird. I'm trying to understand if it's perceived as an issue at the moment before doing anything.
As you said, if I ever add anything will be either an opt-out (data-alpine-no_cache) or maybe even an opt-in mechanism so people don't get errors if they update without reading the release notes.
I'm still thinking about it for now.

from alpine-turbo-drive-adapter.

Closing for now. The unexpected side effects are far worse than the benefits.

from alpine-turbo-drive-adapter.