ViewState modification tracking

[viridia]

ViewStates track whether the dependencies of a view have been modified. There are several things that can trigger a build:

• The initial render, which will be called when the parent view builds.
  • Note that Xilem separates out the first build and the subsequent builds as separate methods build() and rebuild(), where the latter takes the previous state as a param. This means twice as many methods, but it avoids needed a default uninitialized state. In Quill, we simply use NodeSpan::Empty as the initial state. However if we start getting into local state we may want to rethink this.
• A change to the presenter's props.
  • When a parent view gets built, it can pass in an updated copy of props. If these are different than the current props, then the view needs to be rebuilt.
  • In Solid and React, these are shallow comparisons, but we don't have that option in Rust. We may have to simply encourage users to design their props to be cheaply comparable.
• A change to one of the view's dependencies.
  • This could be a resource, a component, an asset, etc.
• A change to the view's local state.
  • This really depends on how we want to model local state. There are two options, which are React-like and Elm-like. React-like means having a registry of local variables/signals in the ViewState. Elm-like (which Xilem does) means that the "State" is a generic template parameter of the ViewState, and is returned by .build().

Views are automatically memoizing. This is like Solid and unlike React. In React, re-rendering a parent automatically re-renders its children unless you wrap the component in memo(). Note: we can revisit this decision.

There is also the issue of fine-grained memoization. For example, when tracking a resource for changes, you may only care about one property being changed, you don't want to re-render if anything else changes. We don't have to address this now, it's something to think about for the future.

Like Solid, all tracking is self-erasing / self-healing. All listeners are one-shot, there are no persistent subscriptions. Instead, the rebuild process re-subscribes the listeners as a side-effect.

The way this works is that the space of subscriptions is divided into "tracking contexts". A tracking context has a list of subscriptions and a reaction. For views, there's a tracking context per view state.

When a subscription is triggered, it does not immediately invoke the reaction, but marks the tracking context as modified. The "update" system does the following:

• For each modified tracking context:
  • Clear all subscriptions.
  • Run the reaction (which calls the ViewState .build() method.

Note that triggering a rebuild of a parent may also cause a rebuild of its children. This might cause build to be called twice if both parent and child are marked as modified. To avoid this, we'll want some way to (a) have parents build before children, and (b) mark the children as unmodified when they are rebuild, even if the rebuild was caused by something other than the child's reaction.

Dropping / despawning: there are several cases where view states can be dropped:

• When the entire view root is despawned.
• When a child of an if branch is not taken.
• When the number of items in a for/each loop changes.

In these cases, we'll want to ensure that there are no remaining subscriptions for the view state, because we don't want to run the reaction for the despawned elements.

[viridia]

There's been a lot of progress on this, although much remains to be done.

Despawning of View is done by the raze() method. Updating in response to resource changes works, but other kinds of updates are not yet tracked.