Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Many web applications use DOM elements to store application state. It’s better to store application state in pure Javascript objects to achieve simpler designs with have better performance and less complexity.

 Instead store state in Javascript objects

It’s better to represent application state information in Javascript objects which should be the source of truth and then just display this information in the DOM.

i.e. Application State In Javascript → rendered into → DOM

never

DOM → state extracted → Application state.

 Example - a tree control

For instance if you were writing a tree with expanding nodes then one would want to store information about the nodes in a Javascript tree and then just have some code to display using HTML tags (aka DOM).

 How do you map from DOM elements like for mouse clicks?

You have to get used to the idea of writing some code which manipulates DOM objects and then establishes a simple map back to your object model.

So for a tree control for instance when a user clicks on a item in the tree one needs code to traverse the parents and come back with an array of the location in tree.

One one has the location address one can then map into the Javascript objects which are your source of truth.

 This is an example of applying separation of concerns

The data model represented in Javascript objects has the actual state.

The DOM objects just represent a view of that state.

See Separation of Concerns

 This approach avoids the headache of special characters

One nice thing about this design approach is one is saved all the headaches of needing to escape special characters that conflict with HTML etc.

 The DOM element objects end up simpler and there is less memory overhead

DOM objects are big. The browser needs to maintain a lot of state for each DOM object about it’s location, how it’s rendered etc.

It’s much less expensive to represent this state using Javascript objects.

 DOM objects can then be transitory - the state can be kept even if elements are not showing

Say you have a tree control with a lot of state about the expansion

 Javascript objects are just dictionaries, arrays and simple type. The model can fit the application needs.

We can pick data-structures which are convenient to our application.

Javascript objects that we define for our needs are easier than dealing with all the obscure quirks of thirty years of history with the browser APIs for DOM objects.

This is much better than putting state on DOM objects which are in an arbitrary tree structure for how they are displayed in the browser.

For instance for the tree control example it makes sense to have a nested dictionary that stores the tree data but for the expansion nodes to have that stored in a flat dictionary mapping the IDs of nodes which need to be expanded.

  • No labels