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 8 Current »

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.

 Putting application state into DOM elements makes for very complicated markup
dom complicated.mp4

This video shows the complexity of the Confluence DOM tree versus how I am doing it.

 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.

simpledata.mp4
 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.

traverse mouseclick.mp4
 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