We've recently released our Angular 2 Guidelines. As a result, I'd like to take a moment to explain why, and how, they were developed.
Getting started with Angular 2
When starting a project, developers very often have to decide how to structure and write their applications. This first step is even more important when working on large projects, with a large team. Decisions that work just fine when the application is small or even medium-sized tend to fall apart very quickly under the strain of a large, complex and ever-changing body of code. To make matters worse, these same decisions form the foundation of your application and become significantly more difficult to change as the application grows. Teams undertaking a new project must then lean on their previous experiences to ensure the project succeeds down the line.
Style guides help with this process by codifying best practices – which are typically inherited through lessons learned from prior attempts at building the same kind of large applications. While Angular 2 is still young and there are fewer lessons to draw upon, a few have already materialized. Our intent isn't to simply add to their number. Where they presented good ideas, we shamelessly "borrowed" them. You are encouraged to give them a read. Our guidelines, however, aim to go further.
The old saying that change is the only constant seems eminently applicable to software development. In the general case, then, we strive for codebases where the developer can be confident making changes to the application. This requires that those changes be predictable and that the program be easy to reason about. In that pursuit, we've reached for familiar and battle-tested constraints. In the small, we prefer a functional style where our abstractions are built from small functions operating over immutable data. In the large, we leverage Redux for state management and pair it with a large collection of small state-less view components in order to display our UIs. Between them are a few container components that provides behaviour and data from Redux to the view components they contain.
Open-sourcing how we think
It's worth explicitly stating that the Angular 2 Guidelines are a living document and a work in progress. They're informed by our experiences thus far and the practices that have worked for us across a varied range of Angular 2 projects at Rangle.io. They may very well change as we learn more. While the guidelines are opinionated, they are first and foremost pragmatic.
We've released them primarily to share our thinking with the community. We not only welcome but encourage questions and discussions. If you follow our guidelines and they fail you, we'd love to hear about it. Any discussion of best practices and style risks being derailed by minor preferences based on aesthetics or simply familiarity. To prevent this requires understanding intent. While the how is important, we hope this post gave you an idea of why we propose doing things the way we do.
More Angular 2 Resources
2-day Training with our experts, available online next week! Dive into Angular 2's component model and start thinking differently about your application architecture.
Rangle's Angular 2 Resource Page has a tonne of great content to help you dive into all things Angular 2. Check it out for our other related blog posts, webinar recordings, and more.
Rangle's Angular 2 Newsletter
Sign up for our dedicated Angular 2.0 newsletter, to gain insights on best practices and how to strategize your shift: