As I write this in April 2016, Angular 2 is in beta (with a recent comment from Google about a release candidate coming soon), and while it is still early days for production Angular 2 use, we already know of a number of projects (including here at Oasis Digital) heading rapidly in that direction.
Looking around the Internet, listening to the podcasts, reading the blogs, watching the GitHub repositories, we have seen a surprising early emergence of an architectural preference with Angular 2. Here is our expression of this preference, I’m sure a group of thought leaders could gather and each would have a different take on it of course.
In a complex Angular 2 SPA:
- Avoid the “bucket brigade” of data binding business domain data one component at a time across an application component hierarchy. The new syntax makes each step of the bucket brigade tidy, but still ultimately error-prone and tedious. One binding is good, a series of bindings one to the next is not.
- Avoid unmanaged state floating in a bunch of stateful services (classes) – now that it is easy and fast to create these as plain classes with Angular 2, it is also easier to create a complex enough system that unmanaged state leads quickly to slow, error-prone, complex development.
- Use RxJS heavily. There is some dispute around the web as to whether RxJS is the most ideal implementation of reactivity, but it is emerging as the most popular, and the one most similar to an upcoming likely standardized API.
- Adopt the Redux / Elm architecture, coalescing all application state to a central (but hopefully well-modularized) data store, mutated only by the processing of actions using reducers.
- The early leader as the “glue” to do the above in Angular 2 is ngrx/store.
- Test essential logic at that central state.
- If you happen to be using a Node backend, it it very easy to share data structure definitions and UI-free application logic between client-side and server-side code. Do so as needed.
We have adopted this architecture where suitable, we see lots of activity around the web which indicates others are adopting something similar. This approach generally is likely to emerge as the dominant approach in complex Angular 2 development. Further, it appears to be part of a growing trend across a variety of SPA libraries/frameworks. Whether using Angular 2, AngularJS, React, Cycle, Vue, OmNext, etc., this idea of state separated from UI logic is compelling.
(Conveniently, here at Oasis Digital, we are deeply familiar with CQRS/ES, and this Elm/Redux architecture echoes quite strongly of that.)
What does this mean for Angular 2 development? I think most likely it means: the differences between Angular 2 and its competitors are growing less important. If you are managing state in a centralized, decoupled manner anyway, the choice of UI / view layer becomes more a matter of development preference than before. This is a tremendously positive development.