Quick question, is there any downside on always using patch
over navigate
in <.link
?
As far as a quick tests shows me patch
seems to work just fine even if it goes to a different liveview? So why would I add the mental/maintance overhead of picking the “correct” one?
Leaving state where the intention is to start with fresh state will leave you with strange bugs to deal with. I support using navigate
everywhere possible over attempting to use href
for deadviews, but patch should imo really be used where actually intended.
2 Likes
What does this mean?
From very limited observation I don’t see anything weird happening when patching
between different liveviews. mount
is called when switching and everything seems to be working correctly.
Furthermore, I’m wondering if it’s not possible to automatically detect if we could patch or not?
My point here is that you don’t want to use patch in all the places where you can patch – to the contrary. The default case is that a page navigation starts from scratch, given that’s both the simpler to understand as well as program option.
Only if you actually need to retain state in the LV across the navigation (within the same LV) should you opt into the greater complexity of doing a patch and the related larger state space and increased state change over time. That decision cannot be automated.
Unintentionally retaining state in a LV on navigation, which happens to land on the same LV again, could easily retain state that’s meant to be reset leading to unintentional bugs. Bugs which are also hard to catch in common lv testing, where you’d unlikely test a lot of cross page navigations, but usually stick to functionality within a single page.
Ah, so the issue is not for the other LVs, but for the same LV where you might return to, that you still have the previous state.
That makes sense. Thanks