Not sure what you mean by this. The url path is constructed as soon as all the params are known (btw, we don’t pass just the coordinates, there’s some other app specific stuff, but that’s out of this scope).
You could use a string (the event name) for input but then you would still need to wrap it into a %JS{} so the dispatch can take place in the same turn and before the push/navigate.
For what I know (paid attention to) LiveView “only” restores the form client side input values.
As far as I can tell from the suggestion, it’s about constructing the target path from the params available in the template so it’s clearer what’s going on and I support it, but having this “back/refresh” functionality is more complex than that. There’s also the resolution part the url params get interpreted and acted upon (like el.scrollIntoView stuff).
I agree it’d be nice if the whole pattern was generalized and built into LiveView. However, it’s not as straight forward as it may seem because there are parts that may differ from app to app depending on the requirements.
For instance, in our case we don’t simply append the additional (“coordinate”) params to the url, but we encode them first into a single one. It’s not for some security reason (there was no such requirement), but I wanted to make sure it’s either valid as a whole or invalid (without adding yet another checksum param, for there are length constraints there, especially if you account for the default config limitations of Kubernetes and such). Someone else might have opted for storing them server-side completely (like in a GenServer or ETS or even a frontend DB), while only appending a single id if the requirement was to hide the inner doings completely, and so on.
