My vision is for Lateralus to work as well as an addition to Backbone as it would to, say, React. Lateralus provides a set of generally useful patterns that should be employed in any application, UI-based or not, Backbone-based or not. Like Backbone, Lateralus’s application primitives are universally relevant. Here, I hope to describe some of these patterns and why they matter.
Everything is a component
Any application can be thought of as a set of components. Here’s a quote that I often use to explain why:
“The secret to building large apps is NEVER build large apps. Break up your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application.”
This could be though of as a reframing of Separation of Concerns. You can bet the farm on this concept, it will never become irrelevant. Legos are powerful because they consist of tiny blocks that can be easily reconfigured into entirely new structures. Components are a first-class citizen in Lateralus, and act as a means of separating your application into lego blocks.
A component-based structure is rarely flat. Instead, components are often nested, sometimes many levels deep. Any component-based application framework must allow for this, therefore Lateralus provides facilities to do so. Also important is the ability to arbitrarily remove components at any depth, and have the nested components clean up after themselves transparently. Lateralus provides APIs for this as well.
If nothing else, Lateralus is a set of patterns to decouple application code. In fact, tight coupling is the problem that Lateralus was built to solve. Generally, components should be built to have little to no awareness of each other. Each application component is built to be aware of only itself and almost nothing else. However, in order for Lateralus to be practical in real-world development, there is a minimal set of inter-component relationships that are defined.
Nested components sometimes need to have some awareness of the parent component that they belong to. This pattern can be easily abused, as all patterns can be, but sometimes it’s just easier, clearer, and more performant to directly access a parent or child component than to over-engineer excessive abstractions to avoid it. Lateralus provides a direct link to the parent, as do views.
Central application relationship
Components often need some awareness of the universe they exist within, and the singular
Lateralus instance is that universe. A begotten
Lateralus object should typically contain general-use utility APIs, and all Lateralus objects can access those APIs via
this.lateralus, no matter where they exist in the component hierarchy.
Because Lateralus provides utilities for creating a well-structured, decoupled component hierarchy, it must also provide utilities for these components to indirectly communicate with each other. One of the most frequently-used APIs in a Lateralus app is
emit, which broadcasts a message globally to the entire application. You are free to namespace these messages as you see fit, but Lateralus aims to be flexible by default. All Lateralus objects can arbitrarily listen for
emitted events via the
lateralusEvents map. The
lateralusEvents relationship is one-to-many: You can attach as many listeners to an
emitted event as you need.
Observable data models
Data is core to any application, and Lateralus makes that data powerful. Especially when you are working with application state, many components may be concerned with when a piece of data changes. Lateralus makes it easy to associate a component with a model. Data changes within a component’s model are observable, thereby allowing listening objects to be notified. The central
Lateralus model is even more powerful because it broadcasts specific model attribute changes to the entire app.
Scalable patterns for large apps
At an implementation level, Lateralus is currently an extension to Backbone. However, I hope to evolve it to be more than a Backbone bolt-on. I think it’s more effective to frame Lateralus as a set of patterns to incorporate into any application, whether or not they use Backbone. These patterns have so far proven to be very effective for organizing and scaling a number of codebases at Jellyvision, and I hope to develop them further and fill in the gaps as I discover them.