Frameworks are not architectures. However, at least in the frontend world Angular is somewhat frequently spoken of as if it were a full set of opinions, structures and design patterns. This is a mistake. What Angular does do is provide a set of tools so that you have the foundational pieces for as many different architectures as possible. But in no way, shape or form do these constitute an architecture on their own simply because these tools are bound together.
Put simply, an architecture involves definitions with regards to "how things will be done and organized" and how to define "things" and distinguish between them (among other things the definition might include). However, while that truthism sounds relatively straightforward, architectural decisions are anything but. The decisions are typically based on deeply technical factors centered around how categories of entities are defined and the design patterns that a team wants to use or avoid.
Going with this, "we use injected services" is not a statement of architectural significance for a variety of reasons, the largest being that there is no distinction about what logic does or does not belong in a service. To put this into the context of Angular, Angular services are on their own nothing more than a class that has a fancy way of being provided to your components at construction. You have as many design choices with Angular services as you can with anything else, be it Webpack provided singletons containing helper functions, Redux's reducers and actions, or pure Typescript. You also can easily make just as many mistakes. Nothing is stopping you from having non-change detectable state changes in your services, or from using HTTP interceptors in ways that hijack API request logic flow, or from abusing RxJs to create a single giant global state object that all components subscribe to and update directly.
"We use injected services…to manage state that is shared between components, and to handle business logic in a place outside of reusable/generic components" on the other hand is an architectural significant statement. It makes it clear that lines have been drawn (hopefully in greater detail than this) to help the team mentally separate out different pieces of functionality. It also helps suggest design patterns on how to make and keep those pieces separate. Another example would be using explicitly divided up groups of components, such as core UI/stateless components vs layout or use-case specific components as is common in a "presentational and container" components approach.
But the important thing to note is that this isn't something Angular created for you. These divisions do not exist within Angular, nor are they in any way inherent to it. Neither are these things an inherent part of React, Typescript, or RxJs. These libraries and packages are simply curated toolboxes (or an individual tool themselves) that have been put together with an eye towards promoting or avoiding various patterns, while leaving the door open as much as possible to whatever else is out there. And in any discussion of Angular it would be a mistake to not take note of the immensely valuable foundations for so many different architectures that Angular provides, and how it does so with such agnosticism. (It can also be argued that Angular entertains too many different approaches, but that is a different discussion)
Taking all of this a step forward, even if there were explicitly chosen best practices in Angular (or anything else) that clearly favored certain architectural choices (some contenders are RxJS backed reactive programming and "data down, actions up"), there is nothing forcing you to accept these choices. As long as you stay within the bounds of decent coding patterns and make informed decisions that do not conflict with each other, there is no reason why you cannot pick and choose as you want, or even forge an entirely new path.
But, be careful. Pick carefully what problems you can solve on your own, and maybe prefer existing patterns for things that have given you trouble in the past. Take into consideration the way things are currently being done and "the way the author(s) suggest", but don’t take it as gospel. There are many ways forward; your framework isn't the whole house, but it should always help you open doors to the ways forward that you can best envision and act upon.
Top comments (0)