Refactoring Angular Applications

Chapter 9. Refactoring to Patterns

Modern JavaScript frameworks have enabled a new style of writing web applications, but patterns and practices from earlier technologies have led us to make suboptimal design choices in our applications.

The patterns used for the previous generations of web applications are outdated, but old habits die hard. The patterns that worked well for server-side web apps don’t fit very well into the single-page paradigm. JavaScript enables the user’s web browser to do much of the work we used to do on the server, but now we need to start thinking in terms of components, smaller bits of functionality that create an experience for the user.

Angular is sometimes called a model-view-whatever (MVW or MV*) framework, but actually its support for models offers developers very little help. As a result, anemic models, i.e., plain JSON, are the default choice for model patterns. Behavior is added through a service (which is not great) or through a controller (even worse).

Two-way data binding is amazing compared to the way data binding worked in previous frameworks. Two-way binding allows form fields and DOM elements to be instantaneously and effortlessly synchronized. Angular promised us power and simplicity with two-way binding, but as our use cases grow in complexity, our code actually becomes more difficult to reason about and is less performant. The unidirectional data flow architecture popularized by React offers us a clearer pattern that we can immediately ...