[<<][webdev][>>][..]
Tue Aug 29 03:20:38 EDT 2017

React vs. presentation model diffing

Woke up after looping on something about setting attributes.  Can't
make much sense of it...  This is going to sound a little confused.

This is about full-blown React, vs diffing the presentation model and
mapping diffs to imperative widget updates.

The model diff doesn't work well for deep structural differences.  It
is a hack that works as long as layout doesn't change too much, or if
the changes are easy to express as method calls.  Ether turning things
on and off, pushing new inner layout, or having a little more smarts
on the javascript side to push a component.  React could still be
useful there.

What is cool about React, is the ability to make components without
worrying about how to specify construction imperically.  The method I
came up with is stricly less powerful in that it strongly relies on
being able to push most of the layout initially, and then do simple
tweaks on that tree later on.  It is still server-side, with React
being fully client side.

This is a really interesting and seemingly deep subject.

I do wonder: in a pure react rendering, there is a mapping of an
algebraic data type to layout.  The alternatives (sums in the type --
different constructors) lead to different layout.  You need a react
style if there is any kind of recursion going on, because that needs
to be "flattened out" in the document + node switching.

The essence of the react approach is that construction is done
programmatically.

However in practice it seems that this is not needed beyond simple
things like lists.

Actually lists are a good example of the turning point of complexity.

Bottom line: react is about rendering algebraic data types.  The other
approach does the same initially, but then performs modifications on
the tree, possibly re-rendering subtrees.

In the tree diff, there are 3 operations:
- ins, del, set

The approach I used up to now relies on all structural modifications
being limited to removing and adding (known) elements to a list.  The
type is in essence not recursive -- only at initial rendering time,
but not at update time.

In cases where structure does change, it probably makes sense to push
the constructor code into the javascript, and rebuild nodes
incrementally.

I.e. instead of a constructor, the constructors are encoded
differentially as: ins, del, set.

It's probably possible to build that translation programmatically as
well.  Express the component as a pure function (in a sane language)
and derive the ins, del, set differential constructors.




[Reply][About]
[<<][webdev][>>][..]