Clojurians Log v2

Inspector showing properties of an app node. • pink labels mean property is backed by a formula; • cyan labels indicate backing by an input cell; • all values truncated to 40 characters; and • bless CLJ, function snippets come for free from str applied to functions. btw, "selected-lesson" may sound like an input because the user controls that, but it is a formula working off the input "route". Next up, a drill down into the cell structures.

I could not resist. The tooltip for a label for a property backed by a formulaic cell is the formula code, pretty-printed:

And the Wiki update: https://github.com/kennytilton/web-mx-workshop/releases/tag/model-show-properties So this whole journey has been as much about me trying to understand why w/mx, and other mx-wrapped UIs, are so effective, just so I can better pitch the approach. Made some progress on that, and it comes back to components, indeed properties of components, being empowered to gather information at will, by navigating from the formula anaphor me out to the surrounding MX to find whatever information that property requires to decide its value. Flux-based UIs have some of that, in that they can reach out to subscriptions in the external store at will for data, but there we have view functions looking for several subscriptions that will be needed to satisfy all the value decisions of all the elements of the component. And the programmer has to find the right subscription, possibly make a new one. This obscures the connection between property and subscription. With w/mx, as we code each property we concoct a bespoke formula that navigates as needed to specific other properties. For one thing, this means not relying on a parent container passing props. This in turn means we can shuffle components and formulas around at will, because information is collected internally, by formulas that have their own smarts. With Flux, we have to wire components together, parent-to-child with props, or at best deal with the Flux boilerplate to arrange a global subscription. Speaking of global, I noticed while hacking together the inspector that a lot of state dependency is quite localized. The display for an inspector node of an app node dealt quite a bit with two flags, show-kids? and show-props?. Well, we just made those input cells. We did not need to deal with anything external. There was no reason for those to be in a Flux store for elements to decide their state, and the onclick handler just needed to tweak those two nearby input cells. Well, I guess this is where hooks come in. What w/mx may still have going for it is that where a React app has props, hooks, and Redux, w/mx just has uniform, in-place state, accessed transparently. 🤷 Next up, I think the inspector needs to have tabbed views, which can be locked on individual inspected nodes while we navigate elsewhere to chack sth else. Note that I am just brainstorming, not really being driven by using the inspector in anger and discovering requirements. Anyone with ideas for the inspector, the suggestion box is open.