Skip to content
This repository was archived by the owner on Dec 4, 2017. It is now read-only.

docs(style-guide): edit copy #3020

Merged
merged 2 commits into from
Jan 3, 2017
Merged

Conversation

kapunahelewong
Copy link
Contributor

Copy edits to the style guide. @wardbell I toned down some of the case recommendations but can revert if you prefer.

Copy link
Contributor

@wardbell wardbell left a 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.
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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.

Copy link
Contributor Author

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.
Copy link
Contributor

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.

Copy link
Contributor Author

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.
Copy link
Contributor

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, or Service) for a thing of that type.

Copy link
Contributor Author

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.
Copy link
Contributor

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.

Copy link
Contributor Author

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).
Copy link
Contributor

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.

Copy link
Contributor Author

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.
Copy link
Contributor

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 .
Importing CoreModule into the root AppModule reduces its complexity and emphasizes its role as orchestrator of the application as a whole.

Copy link
Contributor Author

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.
Copy link
Contributor

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.

Copy link
Contributor Author

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.
Copy link
Contributor

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.

Copy link
Contributor Author

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.
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replaced.

@wardbell wardbell merged commit 6d431f1 into angular:master Jan 3, 2017
@wardbell wardbell deleted the wong-style-guide branch January 3, 2017 20:44
abdel-ships-it pushed a commit to abdel-ships-it/angular.io that referenced this pull request Feb 11, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants