Model the information, not the screen coordinates.
A registration has a name, a number of places and perhaps a nested address. These values belong together even when they are shown in different panels. A Bag gives the application paths for that structure; bindings connect those paths to the interface.
Moving a field does not require turning its DOM position into its identity. The application still talks about the registration’s data.
Types matter after the first edit.
A date is not just a caption and an exact Decimal is not interchangeable with every numeric representation. Typed controls and the typed exchange format help keep values meaningful as they move through the page.
For saved drafts, TYTX preserves the types used by the Bag. For JSON or XML interchange, choose a schema that makes the textual representations clear to the receiving program. A JSON export is not the same promise as a typed round trip.
Declare initial values deliberately.
dataSetter installs a value at a path. A dictionary supplied in the supported position becomes nested Bag data; a JSON string remains a string and is not implicitly parsed. That distinction avoids a page silently guessing what an input meant.
pane.dataSetter(".record", {
"name": "Ada",
"seats": 2,
"confirmed": True,
"address": {"city": "Rome"}
})Read the explanation here. The working lesson and full contract are linked below.
Make the state visible while learning.
The inspector exposes Data alongside Source. Use it to follow the value behind a textbox, then compare it with the displayed text and field state. This is particularly useful with validation, where a visible draft and accepted Data can differ.
A Bag is application state. It is not, by itself, a database transaction, an automatic save service or a synchronization system.