Clojurians Log v2

I feel a little confused about the order in which the things have to be re-computed / updated. It seems that re-computation of values have to go from the local db reads to the places where the html node need to read them. But at the same time, it seems that the html node updates have to go from the root node to the leaves, because some branches may be created or removed via branching in the rendering process (the if and for).

The 2 update processes have to meet somewhere in the middle.

I can see that 2 things can be separated: • Finding which compute nodes are affected by a change in the local db without calculating the new values (but potentially including with some false-positives). • Calculating the new values of the compute nodes.

It would be nice if we could have a multi-stages update, for a better efficiency: 1. Find which compute nodes are affected by a change in the local db. Select only the few which are potentially causing the creation and destruction of html nodes (i.e. some of the if and the for blocks). Calculate their values. 2. Get a new html node tree where the if and for have already been taken care of, including in the newly created html nodes. Some compute node may be deleted, and new ones may be created. 3. Calculate all the compute nodes whose inputs have changed and which did not already recomputed their output. We can even include the html nodes in this part of the update process. That multi-stage process implies that we differentiate between the nodes which are creating/destroying nodes (let’s call them the structural nodes) from the other nodes (let’s call them the content nodes). ⭐

One of the objectives of the Diffuse library was to be used by the user to describe the changes to the local db via a diff. A hidden objective was to have the diffs propagated through the graph of computations, with the user describing their outputs using diffs as well. It would be particularly useful for the for node because we would know the indices of the elements which have changed and would not need to look for them. It would also be particularly useful in some compute nodes which can be written in an incremental manner. For instance, in a node which would produce a reverse relationship between large groups of entities, an incremental change of the input could be described as an incremental change of output in a blazing fast way without having to iterate on all the members of the groups.

(time to work, end of the brainstorming for me. @yogthos: I would be happy to get your feedback on the html updating process. -marked with a ⭐)

Yeah that seems reasonable to me, basically you'll have nodes that generate dynamic content, and they need to update intelligently when the content changes. Ideally for dynamic collections you'd want to have the node managing the collection be able to figure out the specific items that changed and only replace those

there's a fixed set of operations that can happen there, you could add an item, remove an item, change order, and update

so for example if there's an html table being rendered, then it has to be able to handle these operations with minimal updates to the DOM