Chapter 3. Component Composition

Large-scale JavaScript applications amount to a series of communicating components. The focus of this chapter is on the composition of these components, while in the next chapter we will look at how these components communicate with one another. Composition is a big topic, and one that's relevant to scalable JavaScript code. When we start thinking about the composition of our components, we start to notice certain flaws in our design; limitations that prevent us from scaling in response to influencers.

The composition of a component isn't random—there's a handful of prevalent patterns for JavaScript components. We'll begin the chapter with a look at some of these generic component types that encapsulate common patterns found in every web application. Understanding that components implement patterns is crucial for extending these generic components in a way that scales.

It's one thing to get our component composition right from a purely technical standpoint, it's another to easily map these components to features. The same challenge holds true for components we've already implemented. The way we compose our code needs to provide a level of transparency, so that it's feasible to decompose our components and understand what they're doing, both at runtime and at design time.

Finally, we'll take a look at the idea of decoupling business logic from our components. This is nothing new—the idea of separation-of-concerns has been around for a long time. The challenge with JavaScript applications is that it touches on so many things—it's difficult to clearly separate business logic from other implementation concerns. The way in which we organize our source code (relative to the components that use them) can have a dramatic effect on our ability to scale.