HTML5: Building Rich Domain Components

Now that HTML5 has introduced the concept of Web Workers and has also provided native storage APIs that strongly support asynchronous interactions, many existing Javascript design patterns will have to adapt. This can take the form of making sure all of your Storage Providers are open and ready for action before the user starts to engage with your application, or perhaps it can be as simple as loading assets before attempting to display an element.

Building a Strong Component Model

Below is a definition of  a Component that supports asynchronous load/unload behavior: This type of approach allows us to stabilize Unit Tests on the base implementation and just extend the component for other use-cases.

Avoiding Embedded Calls with a Loader

Using an asynchronous callback pattern will lead to a troubling anti-pattern of many, many embedded callbacks that chain to responses in callback context. This offers challenges in both re-arranging the order of load and generally is hard to read. Here is an example of the type of code to avoid:   Instead, we can use a loader that abstracts away the chained callbacks: With this approach, we load in a collection of components as an ordered list and will just allow the caller to get a single set of callbacks fired. Order dependency can be managed by simple rearranging the list of components at construction. Now, loading a giant set of components becomes as trivial as:  

Testing the Component Base with QUnit

To test our component life-cycle via the loader, lets create a set of default components and validate they all get loaded. Then, we can follow the same pattern for validation of the unload:

Conclusion

With the ability to extend against the Component base and with the advantage of test coverage against the life-cycle of our types, we can begin to start creating a large number of concepts that can be orchestrated together with ease.