• The recursive form element structure is powerful, it allows efficient retrieval and manipulation of elements using their paths. This pattern fits well because we can resolve dependencies and update the UI dynamically and selectively much easier.

Brainstorm:

• tree model: many issues in the previous model were resolved them without even realizing.
• dependencies resolving, tracking: looking up a form element’s dependencies based on its rules and other configuration and track these dependencies changing properties.
• resolving dependencies:
  • Resolve during instantiation (but some are not created yet).
  • Delay resolving until after all elements have been constructed, but some elements might not have been constructed and the decision itself depends on at all because for example their visibility depends on other elements values that are decided after the construction. them when they are created.
  • Lazy resolving: decide when an element wants to decide based on its dependencies that some of them are not resolved, use the resolved one and look up the rest and construct the evaluation context accordingly, is an element still not available yet (different strategies)…etc
• Start/Stop tracking.
• properties values update (the state), the element location on the tree.
• construct the element tree, kick the process of looking up and listening when the widget of the element is built.
• also considering doing this efficiently.
• Sounds like flutter widget tree…
• In Flutter, a widget rebuilds whenever its state changes or a dependency changes. in this model, dependencies are resolved and cached, resolved again (rebuild) (but when the list of dependencies names change not their states), and listen them after each resolving process, the form element may re-evaluate its properties based on another element to reflect the new state. How flutter do this?
• I thought of keeping track of unique key (path).
• If a Field widget depends on another field, its state is evaluated during the build() process. If its dependent field's value changes, Flutter automatically calls setState() to rebuild the widget with the new properties.

👇🏻 it says:

• Whether the [Widget] this context is associated with is currently mounted in the widget tree.
• The [BuildOwner] for this context. The [BuildOwner] is in charge of managing the rendering pipeline for this context. 😀 that’s the reason for the scaffold couldn’t be found in the context.
• in our form model, an element have a parent because I need the element to be able to access information from an ancestor… When I need to look up properties of a parent or sibling field, it's akin to how a widget uses its BuildContext to access information from an ancestor!!!
• It also says in the comments of this code: BuildContext objects are actually Element objects.