Some widgets have a single child and hence need only the property name to that child
whilst others have a list of children and need a name to that list hence either acts as a unifying type to achieve both
Added to functions that should be used as the handler for an event.
If two handlers are found in the same class, they are invoked on the same instance of the class
IFF the actions are triggered on the same widget or a child widget that has had the instance passed to it
Added to classes that are sub-types of TinkWidgetHandler to reigister them for processing behaviour when specific widgets are interacted with in the editor.
Many widgets are stateless but Hypi provides the ability to update their attributes
When that happens, we must rebuild the screen for the changed attributes to show up
If your widget handler is stateful just call setState locally, no need for a global rebuild unless it affects other parts of the UI
It is in effect the same as setState in a stateful widget but does not incur any overhead unless the widget's attribute actually changes
Any data that can be emitted by the application can be stored as variable.
Application variable can be bound in the editor at development time and at run time the values are fetched and used as inputs to workflows
Note that some TinkEditorHandlers like those for form elements have default workflows which bind their values to some variable
The source of a variable is anything that can produce it.
A widget for example can produce the value of one of its attributes which is assigned to a variable
A workflow action as well can output values that is bound as the source of a variable
A variable target is anything that wants to be told when that variable has changed.
An attribute of a widget for example can be bound to a target
This is for "push" based targets. Note that workflow actions use a "pull" based approach where they request the latest value of a variable at any point during their evaluation