Task/Feature:

• Choice Filtering Improvements: Ensure filtering works more effectively.
• Enhanced Rule Processing
  • Solve Tangled Reactivity and the Cumbersome Rule Processing.
  • Independent Rules context and filter context tracking, and evaluation.

Going with The recursive form element structure is powerful (inspired by the way reactive_forms works), it allows efficient easy retrieval and manipulation of elements. This pattern fits well in my case, we can resolve dependencies, bind, decide and update the UI selectively much easier, and the code became less and more readable.

<aside> 💡

A form Element’s dependencies are other form elements referenced in its Rule expressions or choice Filter. Example of a supplier Field of type Text

{
	"name": "supplier",
	"type": "Text",
	"rules": [{
			"expression": "#{transaction} == 'supply'",
			"action": "Show"
		}]
}

Element Evaluation Context

{
"transaction": 'dispense',
"district": "selected([ACT80, ACT40], #{itemType})
",
}

Supplier field dependencies will be the field transaction, and the supplier field will only be visible when #{transaction} = 'supply'. Supplier Field needs to resolve its dependencies (i.e, transaction) during its initialization, cache them and bind to them, and initialize the rules’ actions behaviors referencing these dependencies and cache them too. Whenever the field transaction changes, it will notify all its dependencies, and they will selectively re-evaluate their status and decide which action behavior is in effect. If the expression’s condition is met, the action’s behavior will be queued to be in effect.

With things starting to be more clear, dependencies here are called in Flutter Notifiers, and dependents are called listeners, this is more meaningful terms:

• dependency → Notifier
• dependent → Listener
• notifyDependents() → notify() which only means notify my Listeners.
• Bind to a dependency → a Field register itself as Listener to a dependency
• onChangeDependency() → just onChangeStatus() which means when a Notifier notifies that its status has changed. </aside>

summary of the current implementation iteration as Quick notes, going through each level of processing:

1. extracting/parsing (simple implementation).
2. Resolving Notifiers and registering for listening and initializing related actions behaviors binding to them
3. caching after the first lookup. (If form is large, dependency resolution might get kicked frequently. Improving performance and reduce redundant lookups). Cache resolved notifiers, cache their related actions behaviors
4. Initializing rules’ actions behaviors.
5. triggering either a rule evaluation/action behavior, or a filter Behavior, when a notifier notifies, independently based on which context the changed notifiers are.
6. go through these steps lazily for repeated sections and unloaded sections

State management, minimize rebuild.

Reactive forms state management, statechanged stream, valueChanges stream…etc

Key Design Decisions: