-
Notifications
You must be signed in to change notification settings - Fork 877
Conversation
6329541
to
4ffad06
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I made some more suggestions. I will unblock when you're done.
1. [Appendix](#appendix) | ||
|
||
.l-main-section | ||
:marked | ||
## Single Responsibility | ||
|
||
Apply the [Single Responsibility Principle](https://wikipedia.org/wiki/Single_responsibility_principle) to all components, services, and other symbols. | ||
Apply the [single responsibility principle](https://wikipedia.org/wiki/Single_responsibility_principle) to all components, services, and other symbols. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please revert to Single Responsibility Principle as it is known throughout the world by that name and its initials, SRP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
:marked | ||
The key is to make the code more reusable, easier to read, and less mistake prone. | ||
|
||
The following *negative* example defines the `AppComponent`, bootstraps the app, defines the `Hero` model object, and loads heroes from the server ... all in the same file. *Don't do this*. | ||
|
||
+makeExample('style-guide/ts/01-01/app/heroes/hero.component.avoid.ts', '', 'app/heroes/hero.component.ts')(avoid=1) | ||
:marked | ||
Better to redistribute the component and supporting activities into their own dedicated files. | ||
Redistributing the component and supporting activities into their own dedicated files |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer the infinitive to the participle.
It is a better practice to redistribute the component and its supporting classes into their own, dedicated files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@@ -236,24 +239,20 @@ a(href="#toc") Back to top | |||
|
|||
.s-rule.do | |||
:marked | |||
**Do** use upper camel case for class names. Match the name of the symbol to the name of the file. | |||
**Do** match the name of the symbol to the name of the file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these be two separate DOs?
Do use upper camel case for class names.
Do match the name of the symbol to the name of the file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea. Done.
|
||
.s-rule.do | ||
:marked | ||
**Do** append the symbol name with the conventional suffix for a thing of that type | ||
(e.g., `Component`, `Directive`, `Module`, `Pipe`, `Service`). | ||
**Do** append the symbol name with the conventional suffix for a thing of that type. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the following is better
Do append the symbol name with the conventional suffix (such as
Component
,Directive
,Module
,Pipe
, orService
) for a thing of that type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed.
|
||
.s-rule.do | ||
:marked | ||
**Do** give the filename the conventional suffix for a file of that type | ||
(e.g., `.component.ts`, `.directive.ts`, `.module.ts`, `.pipe.ts`, `.service.ts`). | ||
**Do** give the filename the conventional suffix for a file of that type. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the following is better
Do give the filename the conventional suffix (such as
.component.ts
,.directive.ts
,.module.ts
,.pipe.ts
, or.service.ts
) for a file of that type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@@ -1303,7 +1299,7 @@ a(href="#toc") Back to top | |||
|
|||
.s-rule.do | |||
:marked | |||
**Do** put common components, directives and pipes that will be used throughout the application by other feature modules in the `SharedModule`, where those assets are expected to share a new instance of themselves (not singletons). | |||
**Do** put common components, directives, and pipes that will be used throughout the application by other feature modules in the `SharedModule`, where those assets are expected to share a new instance of themselves (not singletons). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please rewrite as follows:
Do declare components, directives, and pipes in a shared module when those items will be re-used and referenced by the components declared in other feature modules.
Consider using the name SharedModule
, when the contents of a shared module are referenced across the entire application.
Do not provide services in shared modules. Services are usually singletons that are provided once for the entire application or in a particular feature module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@@ -1384,7 +1380,7 @@ a(href="#toc") Back to top | |||
|
|||
.s-rule.do | |||
:marked | |||
**Do** collect single-use classes and hiding their gory details inside `CoreModule`. A simplified root `AppModule` imports `CoreModule` in its capacity as orchestrator of the application as a whole. | |||
**Do** collect single-use classes and hide their gory details inside `CoreModule`. A simplified root `AppModule` imports `CoreModule` in its capacity as orchestrator of the application as a whole. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better?:
Consider collecting numerous, auxiliary, single-use classes inside a core module
to simplify the apparent structure of a feature module.Consider calling the application-wide core module,
CoreModule
.
ImportingCoreModule
into the rootAppModule
reduces its complexity and emphasizes its role as orchestrator of the application as a whole.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@@ -2022,7 +2019,8 @@ a(href="#toc") Back to top | |||
|
|||
.s-why | |||
:marked | |||
**Why?** The Angular DI mechanism resolves all dependencies of services based on their types declared with the services' constructors. | |||
**Why?** The Angular Dependency Injection (DI) mechanism resolves all dependencies | |||
of services based on their types declared with the services' constructors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why? The Angular Dependency Injection (DI) mechanism resolves a service's own dependencies based on the declared types of that service's constructor parameters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@@ -2061,7 +2059,11 @@ a(href="#toc") Back to top | |||
|
|||
.s-why.s-why-last | |||
:marked | |||
**Why?** Data service implementation may have very specific code to handle the data repository. This may include headers, how to talk to the data, or other services such as `Http`. Separating the logic into a data service encapsulates this logic in a single place hiding the implementation from the outside consumers (perhaps a component), also making it easier to change the implementation. | |||
**Why?** Data service implementation may have very specific code to handle the data repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replace #2062-2066
Why? The details of data management, such as headers, HTTP methods, caching, error handling, and retry logic, are irrelevant to components and other data consumers.
A data service encapsulates these details. It's easier to evolve these details inside the service without affecting its consumers. And it's easier to test the consumers with mock service implementations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replaced.
@@ -2084,7 +2086,7 @@ a(href="#toc") Back to top | |||
|
|||
.s-why.s-why-last | |||
:marked | |||
**Why?** Strongly-typed method signatures. | |||
**Why?** Lifecycle hook interfaces use strongly-typed method signatures. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replace this line and next
Why? Lifecycle interfaces prescribe typed method signatures. use those signatures to flag spelling and syntax mistakes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replaced.
4ffad06
to
5b46b44
Compare
Copy edits to the style guide. @wardbell I toned down some of the case recommendations but can revert if you prefer.