Clojurians Log v2

https://book.fulcrologic.com/#_targets_denying_routes_v3_1_23 That function should be pure. It can be called multiple times as part of route finding. It's job is to indicate that the operation is reasonable from that target's perspective. If you want to do confirmation, use route-denied. https://book.fulcrologic.com/#_routing_targets The reason this is separated out is to allow for asynchronous interactions related to routing. Remember that we're trying to write programs that are pure functions of State as The view. So for a given state of the application, one wants a pure representation of the idea that an application is currently in a routable condition, or not. For example an unsaved form. This is what allow route changes for. Now, when the user issues a routing command, we certainly may need to run some side effects, and in fact we may have a fairly complicated UI interaction that we desire as a result of this combination: the user has expressed a desire to change routes, but the application isn't an a state where we feel safe doing that. Thus, the routing system gives us the opportunity to start some sequence of user interactions via route-denied. You may have to retain some information, such as the desired ultimate route, as you do this complex UI interaction. Of course, if JS / confirm seems sufficient, and you can certainly choose to do that, and avoid additional asynchronous code. But, technically, route-denied is the place to put it

Thank you, I finally understand that chapter. In my mind I created state machine where allow-route-change? is terminal, but now I see that route-denied is the way to prepare component to be ready for leaving and even to retry the routing. Great, I like it. And I am not proud, that it takes so long for me to understand the principles.