Usually small JavaScript projects start with simple wiring of callbacks onto DOM elements. This works fine when it the project is in its initial state. But in a short time it gets out of hand. Now we have spaghetti wiring and callback hell. Often at this point we try to get help by looking at adopting a framework, hoping to that its coded best practices draw us out of the mud. But now our project is tied to the new framework.
In search of another, framework independent way I stumbled upon scalable architecture by Nicholas Zakas.
It starts by defining modules as independent units. This means:
- separate JavaScript and DOM elements from the rest of the application
- Modules must not reference other modules
- Modules may not register callbacks or even reference DOM elements outside their DOM tree
- To communicate with the outside world, modules can only call the sandbox
The sandbox is a central hub. We use a pub/sub system:
sandbox.publish({type: 'event_type', data: {}});
sandbox.subscribe('event_type', this.callback.bind(this));
Besides being an event bus, the sandbox is responsible for access control and provides the modules with a consistent interface.
Modules are started and stopped (in case of misbehaving) in the application core. You could also use the core as an anti corruption layer for third party libraries.
This architecture gives a frame for implementation. But implementing it raises other questions:
- how do the modules update their state?
- where do we call the backend?
Handling state
A global model would reside or be referenced by the application core. In addition every module has its own model. Updates are always done in application event handlers, not directly in the DOM event handlers.
Let me illustrate. Say we have a module with keeps track of selected entries:
function Module(sandbox) {
this.sandbox = sandbox;
this.selectedEntries = [];
}
Traditionally our DOM event handler would update our model:
button.on('click', function(e) {
this.selectedEntries.push(entry);
});
A better way would be to publish an application event, subscribe the module to this event and handle it in the application event handler:
this.sandbox.subscribe('entry_selected', this.entrySelected.bind(this));
Module.prototype.entrySelected = function(event) {
this.selectedEntries.push(event.entry);
};
button.on('click', function(e) {
this.sandbox.publish({type: 'entry_selected', entry: entry});
});
Other modules can now listen on selecting entries. The module itself does not need to know who selected the entry. All the internal communication of selection is visible. This makes it possible to use event sourcing.
Calling the backend
No module should directly call the backend. For this a special module called extension is used. Extensions encapsulate cross cutting concerns and shield communication with other systems.
Summary
This architecture keeps UI parts together with their corresponding code, flattens callbacks and centralizes the communication with the help of application events and encapsulates outside communication. On top of that it is simple and small.
Schneide Blog 