search

fulcrologic / fulcro-rad

Fulcro Rapid Application Development
MIT License
201 stars 46 forks source link

Internal route and browser history/address bar mismatch #90

Closed pedrocicoleme closed 1 year ago

pedrocicoleme commented 2 years ago

Hi,

looking at the routing and history system of fulcro-rad I noticed that, when clicking in a link with a rr/route-to!, the browser history change happens in the com.fulcrologic.rad.routing.route-to! function, before the call to com.fulcrologic.fulcro.routing.dynamic-routing.change-route!. So, if the dr/change-route! function cannot change the route, the browser history state and the internal routing state will not match, i.e. the view displayed will be the old one but the route showed in the browser address bar will be the denied route.

There is the dr/can-change-route? function but it does not take into account the :route-denied function possibly supplied in a component, so if we use it to decide whether to change or not the history before calling the rr/route-to! function we would lose the possibility to have an override of that decision. This, indeed, currently happens in the com.fulcrologic.rad.routing.history.install-route-history!, as when trying to change the route via the backward button in the browser the function will only check the com.fulcrologic.fulcro.routing.dynamic-routing.can-change-route?, so if it returns false then the function will refuse to change the route without even trying the :route-denied function.

This analysis came from trying to understand why a link with rr/route-to! and the history backward button showed different behaviours in regards to trying to leave a dirty form in the fulcro-rad-demo app after adding a ::form/confirm function to it.

Are these behaviours as intended?

pedrocicoleme commented 2 years ago

Sorry, just saw I should post it on the fulcro channel, closing it