Feature Request: Supporting better scenario to keep current browser's URL updated

[benjaminweb]

• requirement: share link that contains all parameters to reload site with all its subviews, either on page or in browser URL bar
• observed issues:
  • no option to update URL on changing anything in any subview
  • workaround with route seems to reload the whole page (and closes open web sockets) only to update the browser's URL; there should be a better way to do it
  • it would be nice to have batteries included to generate query args from types and read them back in (currently show breaks that because it does not capitalise the data constructor's names)

[seanhess]

Agreed, this is needed for sure.

[benjaminweb]

Which steps are required to make it happen?

[seanhess]

1. Design the interface - how does the user control this? (This is the hard part)
2. Add a metadata option to the communication protocol that allows the server to set window.history. Something like |HISTORY|/whatever?hello=true
3. Implement it client-side.

[benjaminweb]

Would that be just another event the user has to call?

[seanhess]

Hmm... I'm not sure I love that logic being in the view function. Would it be better in the handler somehow?

[benjaminweb]

You surely know the architecture of Hyperbole better than me :). So what do we have? An action to update the location in the browser, right? And we'd need something to just take care of that. That sounds to me like just another handler, right or wrong?

[seanhess]

My question is a design consideration rather than an architectural one. Is updating the browser's url / history more of a "view" thing, or more of an "effect" thing?

If it were in a handler, it could be added to the Hyperbole effect easily.

myHandler _ DoSomething = do
  ...
  -- this would set the whole thing
  setUrl "/users?filter=active"
  -- this would set only the query, and keep the current route
  setQueryParams [("param", "woot")]
  pure myView

This would result in an extra instruction being sent to the client. We would want to make generating the URL more ergonomic. Probably related to #32 . We need a way to generate URLs from a Route + Query Params.