Clojurians Log v2

@tony.kay I am testing out the history protocol this morning. So far so good. I had to switch to using vreset! in the uir/install-history! fn instead of reset!.

right

Hi @tony.kay - I've been working on this a bit today. Lot's of learning along the way. So far, I have deep linking into a statechart route working along with browser back/forward support. Still need to get RAD form and report controls synced up. There's option to add history support when starting up the statecharts routing (e.g. (uir/start-routing! app application-chart {:history history-impl})). Or roll your own history support. Pushed up a working https://github.com/fulcrologic/statecharts/pull/14#pullrequestreview-2704586540 to see I'm the right path.

sounding right. The report startup logic should be where it re-derives the initial parameters. I think probably in the hook for dynamic routing (report will enter)…

thanks for hacking on it

So this support is half-baked and in serious need of some global ecosystem improvements

So here’s what should happen: • The statecharts URL integration should probably try to extend/use the RAD protocol. But that tangles statecharts with RAD< which I don’t want to do. • So, I need a protocol adapter that can wrap the RAD history support as an implementation, and a new statecharts protocol • The RAD state machines need to be modified so they don’t rely on dynamic routing (e.g. an option that disables that, or a protocol that allows you to config it)…I tied RAD too hard to dynamic routing This means I have to update Fulcro (to add some kind of centralized routing protocol that dr can implement), RAD, statecharts, AND do so in a way that doesn’t necessarily break anything in the ecosystem.

I’ve made a routing-refactor branch on statecharts where I am sort of working on this as I have time

Some things are broken right now in statecharts support: refers to browser stuff which breaks native, but also the RAD URL parameters…for bookmarking. The prior RAD stuff doesn’t integrate with the new stuff correctly because I tied it too close to DR in Fulcro

There’s also a branch on fulcro-rad…I’ll probably create the same branch on Fulcro

It’s a minor refactoring on Fulcro that should be easy once I define the scope. RAD is a little more difficult, but possibly not a lot more. Once I have those generalizations, then fulcro integration on the statecharts can be rewritten in terms of them, and that should fix the issues.

My thinking right now is: • Fulcro defines the abstraction for UI routing…so that protocol goes there. Fulcro itself has no opinion on how you deal with URLs or native “history”. • RAD defines abstractions for history and URL handling which already work. I should re-use those in statecharts integration. I avoided that at first trying to limit deps, but making you require RAD on your fulcro app isn’t a problem. I just won’t add it to the deps of statecharts itself. • The RAD routing also handles “route parameters” I will need to go over the rad-routing stuff and make sure it’ll work ok with the statecharts. The other issue is that statecharts need hierarchy parameters for re-establishing state on bookmarks. This was the complexity I’m dealing with that made me write something new. Every state that you’re entering from a direct route might need to know data for going back to the state it was in. This is actually a big improvement over dynamic routing in a way…in DR you had URL path parameters and that was all. With statecharts you have any amount of clojure-safe data values stored in the “history” (URL)…so much more complex behavior is possible with better structure; however, it puts harder demands on the parameter storage in a URL to prevent conflicts, and the HTML routing in RAD isn’t sufficient, but perhaps that protocol is ok and I just need a new impl.

Shorter description: Top state contains state A which contains B (which is a target UI route). If you’re loading a bookmark then the statechart needs to enter state B, but that means it also enters Top and A, which MAY have had event data or model data in place when they were entered before. The general idea is that anything in the routing tree of the integration is given the chance to “save state” on entry when it’s based on normal transitions, but a direct transition from the root (e.g. a bookmark load) should READ that data from the “history store (e.g. URL)” to recover the desired data model state.

All of this, of course, triggers my “what are we doing making application pages bookmarkable?” as a generally philosophical question of software development…it’s such a disaster of a thing to do well, and there are many many cases that just fail outright because it is a distributed system where restoring the server’s idea of that given application state is almost always impossible. Thus the URL is never really an accurate representation of a “immutable view of the universe” but instead a general idea of some conceptual (and mutable) thing that we want to “make our best effort” to show…which leads to the question of proper error handling.