In this series we look at some of the rules in Angular's Style Guide that might need clarification or alteration as we grow our applications and our understanding 🧠 of the framework.
📐 The Rule in Question: Rule Of One
The Angular Style Guide defines this rule as follows:
Do define one thing, such as a service or component, per file.
Consider limiting files to 400 lines of code.
💡 Positive Observations: A Solid Starting Point
This rule is definitely great advice. It aligns with the Single Responsibility Principle, and motivates us to think about what purpose a component or service in our application really serves.
Choosing 400 lines, as the maximum length per file, is slightly arbitrary, but we should choose some number as a guide post.
Anything that crosses this line is a code smell - not necessarily wrong, but worth further investigation!
Creating multiple components in a single file could make one or both hard to find (at least one class won't match the file name), and as the style guide mentions, the more code in a file, the higher the chance for version control conflicts.
I think this rule is a good starting point, and at the beginning of an application's development there's no reason not to follow it.
👓 What Needs Clarification: Not Everything in our Apps is Angular
This rule has good intentions and is a great suggestion for services and components.
However, most Angular applications are going to include more types than just services and components.
It's common, in a growing or mature code base, to see the following types of things in addition to components and services:
- Domain model classes
- Interface definitions to match API requests / responses
- Type aliases of both of the above, to better match the domain language
- Enum definitions
- Typescript union types
- Custom RxJs operators
- Factory functions for non-class data structures
- Utility functions for validation or transformation
- Classes managed outside Angular's dependency injection system
Do all of these need to be in separate files as well?
State management libraries like Akita and NgRx often have many type definitions to make working with complex and nested state easier.
Since these types are closely related to each other and the state management code that uses them, it makes sense to co-locate them (keep them close in our project).
I think this rule is somewhat influenced by well-known Object Oriented programming languages, like C# and Java, where the type-per-file pattern is well established.
In functional languages, this isn't the case, since functions tend to be smaller and more composable than classes, there are often multiple per "module". This was also true in JavaScript for a long time, which makes sense given the importance of functions in the language.
I really like this quote from Kent Beck (as noted by Mark Seemann):
Mark Seemann@ploeh
The source of one of my favourite @KentBeck quotes was lost to me for years, but today I found it again 😀
"Things that change at the same rate belong together. Things that change at different rates belong apart."
facebook.com/notes/kent-bec…09:45 AM - 28 Mar 2020
✨ Conclusion
Following the "Rule of One" and seeing an increase in the number of files in a project isn't inherently a bad thing!
That said, co-location is also a goal that's worth pursuing - especially for code that is closely related.
I think the "Rule of One" should clearly state the it is a recommendation for Angular types (Components, Directives, Injectables, NgModules, ect...), but we should be free to structure our non-Angular code as the project demands.
As always, thanks for reading 🙏!
❓ Questions
What are your thoughts on the "Rule of One"?
Have any of your apps included the things I listed above, like domain models, Enum definitions, or custom RxJs operators?
Have you ever found the need to move beyond the "Rule of One" for non-Angular code in your Angular application? What about for Angular specific things?
Leave a comment below!
Normally, I'm blogging about Kentico, a content management system I love to use.
We've put together a list over on Kentico's GitHub account of developer resources. Go check it out!
If you are looking for additional Kentico content, checkout the Kentico tag here on DEV:
Or my Kentico blog series:
Top comments (0)