Kids Dyno Mite

This is another easy mission of vital importance: using reactive formulas to make the very content of a GUI interface responsive to the user's work.

easy...

What makes this easy is that we already understand that properties can get their values from formulas. And the so-called kids property of a Matrix model object, unlike the parent property, can be fed by a formula.

What we may not realize is that the mxWeb library understands how to maintain the DOM efficiently as the computed UI changes, so we can enjoy the same declarative freedom that ReactJS provides, without sweating unnecessary VDOM generation and DIFFing.

...but vital

It perhaps goes without saying that a responsive GUI can be a great help to our users. We said it anyway.

lesson objective

Develop confidence in the mxWeb ability to maintain efficiently highly responsive GUIs specified by reactive formulas.

background

ReactJS introduced the world to declarative GUIs, yay, but did so using a "cheat": they rebuilt the UI from scratch after every state change, using VDOM and diff-ing to make it fast.

The problem here is a lack of granularity. The diff has to punt when it sees a difference, and may re-render more than is necessary had the React system tracked state change property by property.

Fun note: the React team now thinks they picked the wrong name. Indeed, they now expressly reject the reactive paradigm. It should have been ScheduleJS, they say, because they want to control when things get updated.

mission requirements

Look in the m20_kids_dyno_mite.core source for "Your code here" and add code to:

• pull the current value from the "Spell me" input;
  • Hint: you want the property value of the widget named :word-to-spell
• convert the word to a list of SPANs, one per letter;
  • extra credit for interleaving hyphens;
• work them into the list of children of the DIV so we see:
  • "The word "booya!" is spelled ...thinking... b - o - o - y - a - !".
• confirm that output changes as you edit the input, including...
• ...showing "Waiting for you to type sth ^^^^." when blank.

Deep Tech

The astute reader will be concerned that the formula that dynamically produces the individual letter SPANs, effectively reshaping the Matrix tree, itself traverses the Matrix tree looking for the input word: (fmu :word-to-spell)

When we accidentally invented Matrix, and got to the point where we were going to have the kids of a node decided by a formla, we were more than concerned; we were pretty sure the reactive party would come to an end. When it did not, we suspected reactive would scale.

That said, we rarely code ourselves into reactive cycles, but when we do it almost always involves an ornate situation where a kids formula depends on state which itself depends on the kids being computed. These are always quickly resolved by some combination of navigating more carefully and relocating state in the Matrix to a more appropriate location.

As a rule, tree search just works. More below on this.

JIT kids

One wonderful surprise about tree search and formulaic kids can be observed if one traces the code with some print statements.

When a Matrix app starts up, there is only one model instance, the matrix root. It has a formula for its kids, and maybe other formulas. Matrix internals just kick these off in no particular order we need to worry about, and everything Just Works(tm). During app start-up, the app matrix is generated JIT as different formulas happen to traverse the app looking for state. Only thereafter do we see "push" dataflow from state change propagating to dependency chains formed during ap start up.

There is a lifecycle requirment here, that once a model instance is generate by a kids formula that it be immediately "awakened", meaning all its properties' formulas get evaluated, likely searching for other model instances and recursively kicking off new kids formulas -- gasp -- but it all Just Works(tm). We take that as a good sign.

wocd?

wocd? is the fget option to search "without-cells-dependency", specifically when reading the kids slot, which may well indeed be mediated by a reactive formula. The deal is this.

Real Matrix applications, and we have written massive apps of several kinds, find other state unconditionally, so the navigation per se to other state does not need to be reactive. Meanwhile, establishing dependencies while navigating would crush performance with excessive dependency tracking.