honeymoose
/
angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-cn/public/docs/ts/latest/guide/style-guide.jade

2274 lines
66 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

include ../_util-fns
:marked
Welcome to the Angular 2 Style Guide
欢迎光临Angular 2风格指南
## Purpose
## 目的
If you are looking for an opinionated style guide for syntax, conventions, and structuring Angular applications, then step right in.
如果你在为语法，规则和Angular应用程序结构寻找一个特定的风格指南，请继续阅读。
The purpose of this style guide is to provide guidance on building Angular applications by showing the conventions we use and, more importantly, why we choose them.
本风格指南的目的是，通过展示我们使用的规则，更加重要的，展示我们为什么要选择它们，来为建造Angular应用程序提供一个向导。
.l-main-section
:marked
## Style Vocabulary
## 风格词汇
Each guideline describes either a good or bad practice, and all have a consistent presentation.
每一个向导描述一个好的或者坏的实践，所有的向导都有一个统一的展示。
The wording of each guideline indicates how strong the recommendation is.
每个向导使用词汇来标志我们推荐的强度。
.s-rule.do
:marked
**Do** is one that should always be followed.
_Always_ might be a bit too strong of a word.
Guidelines that literally should always be followed are extremely rare.
On the other hand, we need a really unusual case for breaking a *Do* guideline.
**做**是我们一直要遵循的规则。
_一直_该词可能有点太强。
指南中标明应该一直遵循的非常少见。但另一方面，我们需要一个非常不常见的情况来打破一个*做*的指南。
.s-rule.consider
:marked
**Consider** guidelines should generally be followed.
**考虑**指南是通常应该遵循的。
If you fully understand the meaning behind the guideline and have a good reason to deviate, then do so. Please strive to be consistent.
如果你能完全理解指南背后的意思，并且有一个很好的理由越轨，那就这么办。但是请保持一致性。
.s-rule.avoid
:marked
**Avoid** indicates something we should almost never do. Code examples to *avoid* have an unmistakeable red header.
**避免**表示我们永远不应该这么做某事。需要*避免*的代码例子会有一个不会错过红色标题。
.l-main-section
:marked
## File Structure Conventions
## 文件结构规则
Some code examples display a file that has one or more similarly named companion files. (e.g. hero.component.ts and hero.component.html).
一些代码例子中会有一个文件，拥有一个或多个相似名字的伴随文件。（比如，hero.component.ts和hero.component.html)。
The guideline will use the shortcut `hero.component.ts|html|css|spec` to represent those various files. Using this shortcut makes this guide's file structures easier to read and more terse.
该指南将会使用`hero.component.ts|html|css|spec`的简写来表示上面的多个文件。使用这个简写可以让本指南文件结构更容易被阅读，更加简洁。
.l-main-section
a(id='toc')
:marked
## Table of Contents
## 目录
1. [Single Responsibility](#single-responsibility)
1. [单一职责](#single-responsibility)
1. [Naming](#naming)
1. [命名规则](#naming)
1. [Coding Conventions](#coding-conventions)
1. [代码规则](#coding-conventions)
1. [Application Structure](#application-structure)
1. [应用程序结构](#application-structure)
1. [Components](#components)
1. [组件](#components)
1. [Directives](#directives)
1. [指令](#directives)
1. [Services](#services)
1. [服务](#services)
1. [Data Services](#data-services)
1. [数据服务](#data-services)
1. [Lifecycle Hooks](#lifecycle-hooks)
1. [生命周期钩子](#lifecycle-hooks)
1. [Routing](#routing)
1. [路由](#routing)
1. [Appendix](#appendix)
1. [附录](#appendix)
.l-main-section
:marked
## Single Responsibility
## 单一职责
We apply the [Single Responsibility Principle](https:\/\/en.wikipedia.org/wiki/Single_responsibility_principle) to all Components, Services, and other symbols we create.
This helps make our app cleaner, easier to read and maintain, and more testable.
我们对我们创建的所有组件、服务和其它标志等，应用[单一职责原则](https:\/\/en.wikipedia.org/wiki/Single_responsibility_principle)。这样能帮助把我们的应用程序弄的干净、易读、易于维护和易测试。
### Rule of One
### 单一规则
<a id="01-01"></a>
#### Style 01-01
#### 风格 01-01
.s-rule.do
:marked
**Do** define one thing (e.g. service or component) per file.
**做** 每个文件定义一个东西（比如服务或者组件）。
.s-rule.consider
:marked
**Consider** limiting files to 400 lines of code.
**考虑** 限制文件到400行代码之内。
.s-why
:marked
**Why?** One component per file makes it far easier to read, maintain, and avoid collisions with teams in source control.
**为什么？** 一个组件一个文件，让它非常容易阅读、维护，并且能防止在版本控制里与团队冲突。
.s-why
:marked
**Why?** One component per file avoids hidden bugs that often arise when combining components in a file where they may share variables, create unwanted closures,
or unwanted coupling with dependencies.
**为什么？** 一个组件一个文件可以防止一些隐蔽错误，这些错误在经常在合并一些共享变量的组件到一个文件时发生，创建不希望的闭合或者依赖耦合。
.s-why.s-why-last
:marked
**Why?** A single component can be the default export for its file which facilitates lazy loading with the Component Router.
**为什么？** 一个单独的组件能是该文件默认的输出，可以支持组件路由的懒加载。
: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*.
下面的*负面*例子定义了一个`AppComponent`，该组件引导了应用程序，定义了`Hero`模型对象，并且从服务器加载了英雄 ... 所有都在同一个文件。 *不要这么做*。
+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.
将组件和支持行为重新分配到它们自己独立的文件会更好。
+makeTabs(
`style-guide/ts/01-01/app/main.ts,
style-guide/ts/01-01/app/app.component.ts,
style-guide/ts/01-01/app/heroes/heroes.component.ts,
style-guide/ts/01-01/app/heroes/shared/hero.service.ts,
style-guide/ts/01-01/app/heroes/shared/hero.model.ts,
style-guide/ts/01-01/app/heroes/shared/mock-heroes.ts`,
'',
`app/main.ts,
app/app.component.ts,
app/heroes/heroes.component.ts,
app/heroes/shared/hero.service.ts,
app/heroes/shared/hero.model.ts,
app/heroes/shared/mock-heroes.ts`)
:marked
As the app grows, this rule becomes even more important.
随着应用程序的长大，本规则会变得更加重要。
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
### Small Functions
### 小函数
<a id="01-02"></a>
#### Style 01-02
### 风格01-02
.s-rule.do
:marked
**Do** define small functions
**做** 定义小的函数
.s-rule.consider
:marked
**Consider** limiting to no more than 75 lines.
**考虑** 限制在75行之内
.s-why
:marked
**Why?** Small functions are easier to test, especially when they do one thing and serve one purpose.
**为什么？** 小函数更加容易被测试，特别是当它们只做一件事，为一个目的服务的时候。
.s-why
:marked
**Why?** Small functions promote reuse.
**为什么？** 小函数促进代码重用。
.s-why
:marked
**Why?** Small functions are easier to read.
**为什么？** 小函数更加容易阅读。
.s-why
:marked
**Why?** Small functions are easier to maintain.
**为什么？** 小函数更加容易维护。
.s-why.s-why-last
:marked
**Why?** Small functions help avoid hidden bugs that come with large functions that share variables with external scope, create unwanted closures, or unwanted coupling with dependencies.
**为什么？** 小函数帮助避免一些大函数与外界互相共享变量、创建不想要的闭合和依赖耦合时带来的一些隐蔽的错误。
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
## Naming
## 命名规则
Naming conventions are hugely important to maintainability and readability. This guide recommends naming conventions for the file name and the symbol name.
命名规则是一个对维护性和可读性非常重要。本指南为文件名和标志名字推荐了命名规则。
.l-main-section
:marked
### General Naming Guidelines
### 常规命名指南
<a id="02-01"></a>
#### Style 02-01
#### 风格02-01
.s-rule.do
:marked
**Do** use consistent names for all symbols.
**做** 为所有标志使用一致的名字。
.s-rule.do
:marked
**Do** follow a pattern that describes the symbol's feature then its type. The recommended pattern is `feature.type.ts`.
**做** 遵循一个模式来描述一个标志的特性和它的类型。推荐的模式为`feature.type.ts`。
.s-why
:marked
**Why?** Naming conventions help provide a consistent way to find content at a glance. Consistency within the project is vital. Consistency with a team is important.
Consistency across a company provides tremendous efficiency.
**为什么？** 命名规则帮助我们提供了一个持续的方法来快速找到内容。在整个项目内前后一致至关重要。在团队内前后一致也很重要。在公司内部保持一致性可以大幅提高效率。
.s-why
:marked
**Why?** The naming conventions should simply help us find our code faster and make it easier to understand.
**为什么？** 命名规则应该简单地帮助我们快速找到我们的代码并让它更加容易被理解。
.s-why.s-why-last
:marked
**Why?** Names of folders and files should clearly convey their intent. For example, `app/heroes/hero-list.component.ts` may contain a component that manages a list of heroes.
**为什么？** 目录的名字和文件应该清楚的说明它们的用途。比如`app/heroes/hero-list.component.ts`包含了一个用来维护英雄列表的组件。
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
### Separate File Names with Dots and Dashes
### 使用点和横杠来分离文件名字
<a id="02-02"></a>
#### Style 02-02
#### 风格02-02
.s-rule.do
:marked
**Do** use dashes to separate words.
**做** 使用横杠来分离单词。
.s-rule.do
:marked
**Do** use dots to separate the descriptive name from the type.
**做** 使用点来分离描述性名字和类型名字。
.s-rule.do
:marked
**Do** use consistent names for all components following a pattern that describes the component's feature then its type. A recommended pattern is `feature.type.ts`.
**做** 对所有组件使用一致的命名规则，遵循这个模式：描述组件的特征，然后它的类型。一个推荐的模式为`feature.type.ts`。
.s-rule.do
:marked
**Do** use conventional suffixes for the types including `*.service.ts`, `*.component.ts`, `*.pipe.ts`. Invent other suffixes where desired, but take care in having too many.
**做** 使用依照惯例的后缀来描述类型，包括`*.service.ts`、`*.component.ts`、`*.pipe.ts`。如果你想，你可以发明其它的后缀，但是请注意不要有太多。
.s-why
:marked
**Why?** Provides a consistent way to quickly identify what is in the file.
**为什么？** 体统一个统一的方法来快速的确认一个文件是什么。
.s-why
:marked
**Why?** Provides a consistent way to quickly find a specific file using an editor or IDE's fuzzy search techniques.
**为什么？** 体统一个统一的方法，利用一个编辑器或者IDE的来快速的模糊搜索技巧，快速找到一个特定文件。
.s-why.s-why-last
:marked
**Why?** Provides pattern matching for any automated tasks.
**为什么？** 为任何自动任务提供一个模式配对。
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
### Components and Directives
### 组件和指令
<a id="02-03"></a>
#### Style 02-03
#### 风格02-03
.s-rule.do
:marked
**Do** use consistent names for all assets named after what they represent.
**做** 为所有东西使用统一的命名：以它们所代表的东西命名
.s-rule.do
:marked
**Do** use upper camel case for symbols. Match the name of the symbol to the naming of the file.
**做** 使用大写驼峰命名法来命名所有符号（类）。配对符号的名字和它所在的文件名字。
.s-rule.do
:marked
**Do** append the symbol name with the suffix that it represents.
**做** 把符号所代表的（比如组件、服务、指令等）附加到符号名字右面。
.s-why
:marked
**Why?** Provides a consistent way to quickly identify and reference assets.
**为什么？** 提供一个前后一致的方法，用来迅速辨识和引用东西。
.s-why
:marked
**Why?** Upper camel case is conventional for identifying objects that can be instantiated using a constructor.
**为什么？** 使用大写驼峰命名法是一个辨识可以使用构造函数来实例化的对象的常规。
.s-why.s-why-last
:marked
**Why?** The `Component` suffix is more commonly used and is more explicitly descriptive.
**为什么？** `Component`后缀是更加常见的用法，它具有精准的描述性。
- var top="vertical-align:top"
table(width="100%")
col(width="50%")
col(width="50%")
tr
th Symbol Name
th File Name
tr(style=top)
td
code-example.
@Component({ ... })
export class AppComponent {}
td
:marked
app.component.ts
tr(style=top)
td
code-example.
@Component({ ... })
export class HeroesComponent
td
:marked
heroes.component.ts
tr(style=top)
td
code-example.
@Component({ ... })
export class HeroListComponent
td
:marked
hero-list.component.ts
tr(style=top)
td
code-example.
@Component({ ... })
export class HeroDetailComponent
td
:marked
hero-detail.component.ts
tr(style=top)
td
code-example.
@Directive({ ... })
export class ValidationDirective
td
:marked
validation.directive.ts
:marked
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
### Service Names
### 服务名字
<a id="02-04"></a>
#### Style 02-04
#### 风格02-04
.s-rule.do
:marked
**Do** use consistent names for all services named after their feature.
**做** 为所有服务使用前后一致的命名规则，以它们的特性来命名。
.s-rule.do
:marked
**Do** use upper camel case for services.
**做** 使用大写驼峰命名法来命名服务。
.s-rule.do
:marked
**Do** suffix services with `Service` when it is not clear what they are (e.g. when they are nouns).
**做** 当不是很清楚它们是什么的时候（比如它们为名词时），添加`Service`后缀。
.s-why
:marked
**Why?** Provides a consistent way to quickly identify and reference services.
**为什么？** 提供一个前后统一的方法来快速识别和引用服务。
.s-why
:marked
**Why?** Clear service names such as `logger` do not require a suffix.
**为什么？** 清楚的服务名字比如`logger`不需要一个后缀。
.s-why.s-why-last
:marked
**Why?** Service names such as `Credit` are nouns and require a suffix and should be named with a suffix when it is not obvious if it is a service or something else.
**为什么？** 服务名字比如`Credit`是名词，需要一个后缀，当不是很明显它是一个服务还是其他东西的时候，取名时应该跟上后缀。
- var top="vertical-align:top"
table(width="100%")
col(width="50%")
col(width="50%")
tr
th Symbol Name
th File Name
tr(style=top)
td
code-example.
@Injectable()
export class HeroDataService {}
td
:marked
hero-data.service.ts
tr(style=top)
td
code-example.
@Injectable()
export class CreditService {}
td
:marked
credit.service.ts
tr(style=top)
td
code-example.
@Injectable()
export class LoggerService {}
td
:marked
logger.service.ts
:marked
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
### Bootstrapping
### 引导程序
<a id="02-05"></a>
#### Style 02-05
#### 风格02-05
.s-rule.do
:marked
**Do** put bootstrapping and platform logic for the app in a file named `main.ts`.
**做** 把应用程序的引导程序和平台逻辑放到一个名字为`main.ts`的文件里。
.s-rule.avoid
:marked
**Avoid** putting app logic in the `main.ts`. Instead consider placing it in a Component or Service.
**避免** 把应用程序逻辑放到`main.ts`里。而是考虑把它放到一个组件或服务里面。
.s-why
:marked
**Why?** Follows a consistent convention for the startup logic of an app.
**为什么？** 遵循一个前后统一的规则来命名应用程序的启动逻辑。
.s-why.s-why-last
:marked
**Why?** Follows a familiar convention from other technology platforms.
**为什么？** 从其他技术平台借鉴一个熟悉的命名规则。
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
### Directive Selectors
### 指令选择器
<a id="02-06"></a>
#### Style 02-06
#### 风格02-06
.s-rule.do
:marked
**Do** Use lower camel case for naming the selectors of our directives.
**做** 使用小驼峰命名法来命名指令的选择器。
.s-why
:marked
**Why?** Keeps the names of the properties defined in the directives that are bound to the view consistent with the attribute names.
**为什么？** 保持指令里定义的属性名字与他们绑定的视图的HTML属性名字一致。
.s-why.s-why-last
:marked
**Why?** The Angular 2 HTML parser is case sensitive and will recognize lower camel case.
**为什么？** Angular 2 HTML剖析器是大小写敏感的，而且它识别小写驼峰写法。
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
### Custom Prefix for Components
### 为组件自定义前缀
<a id="02-07"></a>
#### Style 02-07
#### 风格02-07
.s-rule.do
:marked
**Do** use a custom prefix for the selector of our components. For example, the prefix `toh` represents from **T**our **o**f **H**eroes and the prefix `admin` represents an admin feature area.
**做** 为组件的选择器使用一个自定义前缀。比如，前缀`tod`是从**T**our **o**f **H**eros来的，前缀`admin`代表了admin的特征区域。
.s-rule.do
:marked
**Do** use a prefix that identifies the feature area or the app itself.
**做** 使用一个前缀来识别特征区域或者应用程序本身。
.s-why
:marked
**Why?** Prevents name collisions.
**为什么？** 防止名字冲突。
.s-why
:marked
**Why?** Makes it easier to promote and share our feature in other apps.
**为什么？** 让在其他程序里面促销和共享我们的特性变得更加容易。
.s-why.s-why-last
:marked
**Why?** Our Components and elements are easily identified.
**为什么？** 我们的组件和元素更加容易被识别出来。
+makeExample('style-guide/ts/02-07/app/heroes/hero.component.avoid.ts', 'example', 'app/heroes/hero.component.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/02-07/app/users/users.component.avoid.ts', 'example', 'app/users/users.component.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/02-07/app/heroes/hero.component.ts', 'example', 'app/heroes/hero.component.ts')
:marked
+makeExample('style-guide/ts/02-07/app/users/users.component.ts', 'example', 'app/users/users.component.ts')
:marked
:marked
### Custom Prefix for Directives
### 为指令自定义前缀
<a id="02-08"></a>
#### Style 02-08
#### 风格02-08
.s-rule.do
:marked
**Do** use a custom prefix for the selector of our directives (for instance below we use the prefix `toh` from **T**our **o**f **H**eroes).
**做** 为指令的选择器使用一个自定义的前缀（比如下面例子用，我们使用前缀`toh`，取自**T**our **o**f **H**eroes)。
.s-why
:marked
**Why?** Prevents name collisions.
**为什么？** 防止名字冲突。
.s-why.s-why-last
:marked
**Why?** Our Directives are easily identified.
**为什么？** 指令更加容易被识别。
+makeExample('style-guide/ts/02-08/app/shared/validate.directive.avoid.ts', 'example', 'app/shared/validate.directive.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/02-08/app/shared/validate.directive.ts', 'example', 'app/shared/validate.directive.ts')
:marked
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
### Pipe Names
### 管道名字
<a id="02-09"></a>
#### Style 02-09
#### 风格02-09
.s-rule.do
:marked
**Do** use consistent names for all pipes, named after their feature.
**做** 为所有管道使用前后一致的命名规则，用它们的特性来命名。
.s-why.s-why-last
:marked
**Why?** Provides a consistent way to quickly identify and reference pipes.
**为什么？** 提供一个一致的方法快速识别和引用管道。
- var top="vertical-align:top"
table(width="100%")
col(width="50%")
col(width="50%")
tr
th Symbol Name
th File Name
tr(style=top)
td
code-example.
@Pipe({ name: 'ellipsis' })
export class EllipsisPipe implements PipeTransform { }
td
:marked
ellipsis.pipe.ts
tr(style=top)
td
code-example.
@Pipe({ name: 'initCaps' })
export class InitCapsPipe implements PipeTransform { }
td
:marked
init-caps.pipe.ts
:marked
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
### Unit Test File Names
### 单元测试文明命名
<a id="02-10"></a>
#### Style 02-10
#### 风格02-10
.s-rule.do
:marked
**Do** name test specification files the same as the component they test.
**做** 测试配置文件的取名应该和被测试的组件名字一样。
.s-rule.do
:marked
**Do** name test specification files with a suffix of `.spec`.
**做** 测试配置文件命名应该跟随后缀`.spec`。
.s-why
:marked
**Why?** Provides a consistent way to quickly identify tests.
**为什么？** 提供一个统一的方法来快速识别测试。
.s-why.s-why-last
:marked
**Why?** Provides pattern matching for [karma](http://karma-runner.github.io/) or other test runners.
**为什么？** 提供一个与[karma](http://karma-runner.github.io/)或者其他测试运行器相配的命名模式。
:marked
- var top="vertical-align:top"
table(width="100%")
col(width="50%")
col(width="50%")
tr
th Symbol Name
th File Name
tr(style=top)
td
:marked
Components
td
:marked
heroes.component.spec.ts
:marked
hero-list.component.spec.ts
:marked
hero-detail.component.spec.ts
tr(style=top)
td
:marked
Services
td
:marked
logger.service.spec.ts
:marked
hero.service.spec.ts
:marked
filter-text.service.spec.ts
tr(style=top)
td
:marked
Pipes
td
:marked
ellipsis.pipe.spec.ts
:marked
init-caps.pipe.spec.ts
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### End to End Test File Names
### 端对端测试文件名字
<a id="02-11"></a>
#### Style 02-11
#### 风格02-11
.s-rule.do
:marked
**Do** name end-to-end test specification files after the feature they test with a suffix of `.e2e-spec`.
**做** 端对端测试配置文件应该和它们所测试的特征同名，并加上后缀`.e2e-spec`。
.s-why
:marked
**Why?** Provides a consistent way to quickly identify end-to-end tests.
*为什么？** 提供一个统一的方法快速识别端对端测试文件。
.s-why.s-why-last
:marked
**Why?** Provides pattern matching for test runners and build automation.
**为什么？** 提供一个模式，与测试运行器和自动建造相配。
:marked
:marked
- var top="vertical-align:top"
table(width="100%")
col(width="50%")
col(width="50%")
tr
th Symbol Name
th File Name
tr(style=top)
td
:marked
End to End Tests
td
:marked
app.e2e-spec.ts
:marked
heroes.e2e-spec.ts
:marked
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
## Coding Conventions
## 代码规则
Have consistent set of coding, naming, and whitespace conventions.
采用一套前后一致的编码、命名和空格的规则。
.l-main-section
:marked
### Classes
### 类
<a id="03-01"></a>
#### Style 03-01
#### 风格03-01
.s-rule.do
:marked
**Do** use upper camel case when naming classes.
**做** 使用大写驼峰命名法来命名类。
.s-why
:marked
**Why?** Follows conventional thinking for class names.
**为什么？** 遵循类命名传统规则。
.s-why.s-why-last
:marked
**Why?** Classes can be instantiated and construct an instance. We often use upper camel case to indicate a constructable asset.
**为什么？** 类是可以被实例化并建造一个实例的。我们通常使用大写驼峰命名规则来标示一个可以建造的东西。
+makeExample('style-guide/ts/03-01/app/shared/exception.service.avoid.ts', 'example', 'app/shared/exception.service.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/03-01/app/shared/exception.service.ts', 'example', 'app/shared/exception.service.ts')
:marked
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
### Constants
### 常量
<a id="03-02"></a>
#### Style 03-02
#### 风格03-02
.s-rule.do
:marked
**Do** use uppercase with underscores when naming constants.
**做** 使用全大写，用下划线隔开的方法来命名常量。
.s-why
:marked
**Why?** Follows conventional thinking for constants.
**为什么？** 遵循传统的命名常量的方法。
.s-why.s-why-last
:marked
**Why?** Constants can easily be identified.
**为什么？** 常量可以很容易的被识别。
+makeExample('style-guide/ts/03-02/app/shared/data.service.avoid.ts', 'example', 'app/shared/data.service.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/03-02/app/shared/data.service.ts', 'example', 'app/shared/data.service.ts')
:marked
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
### Interfaces
### 接口
<a id="03-03"></a>
#### Style 03-03
#### 风格03-03
.s-rule.do
:marked
**Do** name an interface using upper camel case.
**做** 使用大写驼峰命名法来命名接口。
.s-rule.do
:marked
**Consider** naming an interface without an `I` prefix.
**考虑** 不要在接口名字前面家`T`前缀。
.s-why.s-why-last
:marked
**Why?** When we use types, we can often simply use the class as the type.
**为什么？** 当我们使用类型时，我们可以经常简单地使用类来作为类型。
+makeExample('style-guide/ts/03-03/app/shared/hero-collector.service.avoid.ts', 'example', 'app/shared/hero-collector.service.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/03-03/app/shared/hero-collector.service.ts', 'example', 'app/shared/hero-collector.service.ts')
:marked
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
### Properties and Methods
### 属性和方法
<a id="03-04"></a>
#### Style 03-04
#### 风格03-04
.s-rule.do
:marked
**Do** use lower camel case to name properties and methods.
**做** 使用小写驼峰命名法来命名属性和方法。
.s-rule.avoid
:marked
**Avoid** prefixing private properties and methods with an underscore.
**避免** 使用下划线为前缀来命名私有属性和方法。
.s-why
:marked
**Why?** Follows conventional thinking for properties and methods.
**为什么？** 遵循传统的命名属性和方法的规则。
.s-why
:marked
**Why?** JavaScript lacks a true private property or method.
**为什么？** JavaScript不支持真正的私有属性和方法。
.s-why.s-why-last
:marked
**Why?** TypeScript tooling makes it easy to identify private vs public properties and methods.
**为什么？** TypeScript工具使识别私有或公有属性和方法变得很简单。
+makeExample('style-guide/ts/03-04/app/shared/toast/toast.service.avoid.ts', 'example', 'app/shared/toast/toast.service.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/03-04/app/shared/toast/toast.service.ts', 'example', 'app/shared/toast/toast.service.ts')
:marked
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
### Import Destructuring Spacing
### 导入声明解构空格
<a id="03-05"></a>
#### Style 03-05
#### 风格03-05
.s-rule.do
:marked
**Do** leave one whitespace character inside of the `import` statements' curly braces when destructuring.
**做** 在解构是，`import`声明的大括号里面留一个空格字符。
.s-why.s-why-last
:marked
**Why?** Whitespace makes it easier to read the imports.
**为什么？** 空格让导入声明更容易阅读。
+makeExample('style-guide/ts/03-05/app/+heroes/shared/hero.service.avoid.ts', 'example', 'app/+heroes/shared/hero.service.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/03-05/app/+heroes/shared/hero.service.ts', 'example', 'app/+heroes/shared/hero.service.ts')
:marked
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
### Import Line Spacing
### 导入声明空行
<a id="03-06"></a>
#### Style 03-06
#### 风格03-06
.s-rule.do
:marked
**Do** leave one empty line between third party imports and imports of code we created.
**做** 在第三方导入和自己创建的代码导入之间留一个空行。
.s-rule.do
:marked
**Do** list import lines alphabetized by the module.
**做** 按模块名字的字母顺排列导入行。
.s-rule.do
:marked
**Do** list destructured imported assets alphabetically.
**做** 按字母顺序排列解构导入行。
.s-why
:marked
**Why?** The empty line makes it easy to read and locate imports.
**为什么？** 空行可以让阅读和定位本地导入变得更加容易。
.s-why.s-why-last
:marked
**Why?** Alphabetizing makes it easier to read and locate imports.
**为什么？** 按字母顺序排列可以让阅读和定位本地导入更加容易。
+makeExample('style-guide/ts/03-06/app/+heroes/shared/hero.service.avoid.ts', 'example', 'app/+heroes/shared/hero.service.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/03-06/app/+heroes/shared/hero.service.ts', 'example', 'app/+heroes/shared/hero.service.ts')
:marked
a(href="#toc") Back to top
a(href="#toc") 回到顶部
.l-main-section
:marked
## Application Structure
Have a near term view of implementation and a long term vision. Start small but keep in mind where the app is heading down the road.
All of the app's code goes in a folder named `app`. All content is 1 feature per file. Each component, service, and pipe is in its own file. All 3rd party vendor scripts are stored in another folder and not in the `app` folder. We didn't write them and we don't want them cluttering our app. Use the naming conventions for files in this guide.
a(href="#toc") Back to top
.l-main-section
:marked
### LIFT
<a id="04-01"></a>
#### Style 04-01
.s-rule.do
:marked
**Do** structure the app such that we can `L`ocate our code quickly, `I`dentify the code at a glance, keep the `F`lattest structure we can, and `T`ry to be DRY.
.s-rule.do
:marked
**Do** define the structure to follow these four basic guidelines, listed in order of importance.
.s-why.s-why-last
:marked
**Why?** LIFT Provides a consistent structure that scales well, is modular, and makes it easier to increase developer efficiency by finding code quickly. Another way to check our app structure is to ask ourselves: How quickly can we open and work in all of the related files for a feature?
a(href="#toc") Back to top
.l-main-section
:marked
### Locate
<a id="04-02"></a>
#### Style 04-02
.s-rule.do
:marked
**Do** make locating our code intuitive, simple and fast.
.s-why.s-why-last
:marked
**Why?** We find this to be super important for a project. If we cannot find the files we need to work on quickly, we will not be able to work as efficiently as possible, and the structure needs to change. We may not know the file name or where its related files are, so putting them in the most intuitive locations and near each other saves a ton of time. A descriptive folder structure can help with this.
a(href="#toc") Back to top
.l-main-section
:marked
### Identify
<a id="04-03"></a>
#### Style 04-03
.s-rule.do
:marked
**Do** name the file such that we instantly know what it contains and represents.
.s-rule.do
:marked
**Do** be descriptive with file names and keeping the contents of the file to exactly one component.
.s-rule.avoid
:marked
**Avoid** files with multiple components, multiple services, or a mixture.
.s-why.s-why-last
:marked
**Why?** We spend less time hunting and pecking for code, and become more efficient. If this means we want longer file names, then so be it.
.l-sub-section
:marked
There are deviations of the 1 per file rule when we have a set of very small features that are all related to each other, as they are still easily identifiable.
a(href="#toc") Back to top
.l-main-section
:marked
### Flat
<a id="04-04"></a>
#### Style 04-04
.s-rule.do
:marked
**Do** keep a flat folder structure as long as possible.
.s-rule.consider
:marked
**Consider** creating fodlers when we get to seven or more files.
.s-why.s-why-last
:marked
**Why?** Nobody wants to search seven levels of folders to find a file. In a folder structure there is no hard and fast number rule, but when a folder has seven to ten files, that may be time to create subfolders. We base it on our comfort level. Use a flatter structure until there is an obvious value (to help the rest of LIFT) in creating a new folder.
a(href="#toc") Back to top
.l-main-section
:marked
### T-DRY (Try to be DRY)
<a id="04-05"></a>
#### Style 04-05
.s-rule.do
:marked
**Do** be DRY (Don't Repeat Yourself)
.s-rule.avoid
:marked
**Avoid** being so DRY that we sacrifice readability.
.s-why.s-why-last
:marked
**Why?** Being DRY is important, but not crucial if it sacrifices the others in LIFT, which is why we call it T-DRY. We don’t want to type `hero-view.component.html` for a view because, well, it’s obviously a view. If it is not obvious or by convention, then we name it.
a(href="#toc") Back to top
.l-main-section
:marked
### Overall Structural Guidelines
<a id="04-06"></a>
#### Style 04-06
.s-rule.do
:marked
**Do** start small but keep in mind where the app is heading down the road.
.s-rule.do
:marked
**Do** have a near term view of implementation and a long term vision.
.s-rule.do
:marked
**Do** put all of the app's code in a folder named `app`.
.s-rule.consider
:marked
**Consider** creating a folder for each component including its `.ts`, `.html`, `.css` and `.spec` file.
.s-why
:marked
**Why?** Helps us keep the app structure small and easy to maintain in the early stages, while being easy to evolve as the app grows.
.s-why.s-why-last
:marked
**Why?** Components often have four files (e.g. `*.html`, `*.css`, `*.ts`, and `*.spec.ts`) and can clutter a folder quickly.
.example-title Overall Folder and File Structure
.filetree
.file src
.children
.file app
.children
.file +heroes
.children
.file hero
.children
.file hero.component.ts|html|css|spec.ts
.file index.ts
.file hero-list
.children
.file hero-list.component.ts|html|css|spec.ts
.file index.ts
.file shared
.children
.file hero.model.ts
.file hero.service.ts|spec.ts
.file index.ts
.file heroes.component.ts|html|css|spec.ts
.file index.ts
.file shared
.children
.file ...
.file app.component.ts|html|css|spec.ts
.file main.ts
.file index.html
.file ...
:marked
.l-sub-section
:marked
While we prefer our Components to be in their own dedicated folder, another option for small apps is to keep Components flat (not in a dedicated folder). This adds up to four files to the existing folder, but also reduces the folder nesting. Be consistent.
a(href="#toc") Back to top
.l-main-section
:marked
### Shared Folder
<a id="04-07"></a>
#### Style 04-07
.s-rule.do
:marked
**Do** put all shared files within a component feature in a `shared` folder.
.s-rule.consider
:marked
**Consider** creating a folder for each component including its `.ts`, `.html`, `.css` and `.spec` file.
.s-why
:marked
**Why?** Separates shared files from the components within a feature.
.s-why.s-why-last
:marked
**Why?** Makes it easier to locate shared files within a component feature.
.example-title Shared Folder
.filetree
.file src
.children
.file app
.children
.file +heroes
.children
.file hero
.children
.file ...
.file hero-list
.children
.file ...
.file shared
.children
.file hero-button
.children
.file ...
.file hero.model.ts
.file hero.service.ts|spec.ts
.file index.ts
.file heroes.component.ts|html|css|spec.ts
.file index.ts
.file shared
.children
.file exception.service.ts|spec.ts
.file index.ts
.file nav
.children
.file ...
.file app.component.ts|html|css|spec.ts
.file main.ts
.file index.html
.file ...
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Folders-by-Feature Structure
<a id="04-08"></a>
#### Style 04-08
.s-rule.do
:marked
**Do** create folders named for the feature they represent.
.s-why
:marked
**Why?** A developer can locate the code, identify what each file represents at a glance, the structure is as flat as it can be, and there is no repetitive nor redundant names.
.s-why
:marked
**Why?** The LIFT guidelines are all covered.
.s-why
:marked
**Why?** Helps reduce the app from becoming cluttered through organizing the content and keeping them aligned with the LIFT guidelines.
.s-why.s-why-last
:marked
**Why?** When there are a lot of files (e.g. 10+) locating them is easier with a consistent folder structures and more difficult in flat structures.
:marked
Below is an example of a small app with folders per component.
.example-title Folders per Component
.filetree
.file src
.children
.file app
.children
.file +heroes
.children
.file hero
.children
.file ...
.file hero-list
.children
.file ...
.file shared
.children
.file ...
.file heroes.component.ts|html|css|spec.ts
.file index.ts
.file +villains
.children
.file villain
.children
.file ...
.file villain-list
.children
.file ...
.file shared
.children
.file ...
.file villains.component.ts|html|css|spec.ts
.file index.ts
.file shared
.children
.file nav
.children
.file ...
.file ...
.file app.component.ts|html|css|spec.ts
.file main.ts
.file index.html
.file ...
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Layout Components
<a id="04-09"></a>
#### Style 04-09
.s-rule.do
:marked
**Do** put components that define the overall layout in a `shared` folder.
.s-rule.do
:marked
**Do** put shared layout components in their own folder, under the `shared` folder.
.s-why
:marked
**Why?** We need a place to host our layout for our app. Our navigation bar, footer, and other aspects of the app that are needed for the entire app.
.s-why.s-why-last
:marked
**Why?** Organizes all layout in a consistent place re-used throughout the application.
.example-title Folder for Layout Components
.filetree
.file src
.children
.file app
.children
.file +heroes
.children
.file ...
.file shared
.children
.file nav
.children
.file index.ts
.file nav.component.ts|html|css|spec.ts
.file footer
.children
.file index.ts
.file footer.component.ts|html|css|spec.ts
.file index.ts
.file ...
.file app.component.ts|html|css|spec.ts
.file main.ts
.file index.html
.file ...
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Create and Import Barrels
<a id="04-10"></a>
#### Style 04-10
.s-rule.do
:marked
**Do** create a file that imports, aggregates, and re-exports items. We call this technique a **barrel**.
.s-rule.do
:marked
**Do** name this barrel file `index.ts`.
.s-why
:marked
**Why?** A barrel aggregates many imports into a single import.
.s-why
:marked
**Why?** A barrel reduces the number of imports a file may need.
.s-why.s-why-last
:marked
**Why?** A barrel shortens import statements.
+makeTabs(
`style-guide/ts/04-10/app/shared/index.ts,
style-guide/ts/04-10/app/shared/filter-text/index.ts,
style-guide/ts/04-10/app/shared/modal/index.ts,
style-guide/ts/04-10/app/shared/nav/index.ts,
style-guide/ts/04-10/app/shared/spinner/index.ts,
style-guide/ts/04-10/app/shared/toast/index.ts`,
`example,,,,,`,
`app/shared/index.ts,
app/shared/filter-text/index.ts,
app/shared/modal/index.ts,
app/shared/nav/index.ts,
app/shared/spinner/index.ts,
app/shared/toast/index.ts`)
:marked
.example-title Folder Barrels
.filetree
.file src
.children
.file app
.children
.file +dashboard
.children
.file ...
.file index.ts
.file +heroes
.children
.file ...
.file index.ts
.file shared
.children
.file nav
.children
.file ...
.file index.ts
.file search
.children
.file ...
.file index.ts
.file ...
.file index.ts
.file app.component.ts|html|css|spec.ts
.file main.ts
.file index.html
.file ...
:marked
+makeExample('style-guide/ts/04-10/app/+heroes/heroes.component.avoid.ts', 'example', 'app/+heroes/heroes.component.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/04-10/app/+heroes/heroes.component.ts', 'example', 'app/+heroes/heroes.component.ts')
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Lazy Loaded Folders
<a id="04-11"></a>
#### Style 04-11
A distinct application feature or workflow may be *lazy loaded* or *loaded on demand* rather than when the application starts.
.s-rule.do
:marked
**Do** put the contents of lazy loaded features in a *lazy loaded folder*.
A typical *lazy loaded folder* contains a *routing component*, its child components, and their related assets and modules.
.s-why.s-why-last
:marked
**Why?** The folder makes it easy to identify and isolate the feature content.
a(href="#toc") Back to top
.l-main-section
:marked
### Prefix Lazy Loaded Folders with +
<a id="04-12"></a>
#### Style 04-12
.s-rule.do
:marked
**Do** prefix the name of a *lazy loaded folder* with a (+) e.g., `+dashboard/`.
.s-why
:marked
**Why?** Lazy loaded code paths are easily identifiable by their `+` prefix.
.s-why
:marked
**Why?** Lazy loaded code paths are easily distinguishable from non lazy loaded paths.
.s-why.s-why-last
:marked
**Why?** If we see an `import` path that contains a `+`, we can quickly refactor to use lazy loading.
.example-title Lazy Loaded Folders
.filetree
.file src
.children
.file app
.children
.file +dashboard
.children
.file dashboard.component.ts|html|css|spec.ts
.file index.ts
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Never Directly Import Lazy Loaded Folders
<a id="04-13"></a>
#### Style 04-13
.s-rule.avoid
:marked
**Avoid** allowing modules in sibling and parent folders to directly import a module in a *lazy loaded feature*.
.s-why.s-why-last
:marked
**Why?** Directly importing a module loads it immediately when our intention is to load it on demand.
+makeExample('style-guide/ts/04-13/app/app.component.avoid.ts', 'example', 'app/app.component.ts')(avoid=1)
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Lazy Loaded Folders May Import From a Parent
<a id="04-14"></a>
#### Style 04-14
.s-rule.do
:marked
**Do** allow lazy loaded modules to import a module from a parent folder.
.s-why.s-why-last
:marked
**Why?** A parent module has already been loaded by the time the lazy loaded module imports it.
+makeExample('style-guide/ts/04-14/app/heroes/heroes.component.ts', 'example', 'app/heroes/heroes.component.ts')
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Use Component Router to Lazy Load
<a id="04-15"></a>
#### Style 04-15
.s-rule.do
:marked
**Do** use the Component Router to lazy load routable features.
.s-why.s-why-last
:marked
**Why?** That's the easiest way to load a module on demand.
a(href="#toc") Back to top
.l-main-section
:marked
## Components
### Components Selector Naming
<a id="05-02"></a>
#### Style 05-02
.s-rule.do
:marked
**Do** use `kebab-case` for naming the element selectors of our components.
.s-why.s-why-last
:marked
**Why?** Keeps the element names consistent with the specification for [Custom Elements](https://www.w3.org/TR/custom-elements/).
+makeExample('style-guide/ts/05-02/app/heroes/shared/hero-button/hero-button.component.avoid.ts', 'example', 'app/heroes/shared/hero-button/hero-button.component.ts')(avoid=1)
:marked
+makeTabs(
`style-guide/ts/05-02/app/heroes/shared/hero-button/hero-button.component.ts,
style-guide/ts/05-02/app/app.component.html`,
'example,',
`app/heroes/shared/hero-button/hero-button.component.ts,
app/app.component.html`)
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Components as Elements
<a id="05-03"></a>
#### Style 05-03
.s-rule.do
:marked
**Do** define Components as elements via the selector.
.s-why
:marked
**Why?** Components have templates containing HTML and optional Angular template syntax. They are most associated with putting content on a page, and thus are more closely aligned with elements.
.s-why
:marked
**Why?** Components are derived from Directives, and thus their selectors can be elements, attributes, or other selectors. Defining the selector as an element provides consistency for components that represent content with a template.
.s-why.s-why-last
:marked
**Why?** It is easier to recognize that a symbol is a component vs a directive by looking at the template's html.
+makeExample('style-guide/ts/05-03/app/heroes/shared/hero-button/hero-button.component.avoid.ts', 'example', 'app/heroes/hero-button/hero-button.component.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/05-03/app/heroes/shared/hero-button/hero-button.component.avoid.html', '', 'app/heroes/hero-button/hero-button.component.html')(avoid=1)
:marked
+makeTabs(
`style-guide/ts/05-03/app/heroes/shared/hero-button/hero-button.component.ts,
style-guide/ts/05-03/app/app.component.html`,
'example,',
`app/heroes/shared/hero-button/hero-button.component.ts,
app/app.component.html`)
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Extract Template and Styles to Their Own Files
<a id="05-04"></a>
#### Style 05-04
.s-rule.do
:marked
**Do** extract templates and styles into a separate file, when more than 3 lines.
.s-rule.do
:marked
**Do** name the template file `[component-name].component.html`, where [component-name] is our component name.
.s-rule.do
:marked
**Do** name the style file `[component-name].component.css`, where [component-name] is our component name.
.s-why
:marked
**Why?** Syntax hints for inline templates in (*.js and *.ts) code files are not supported by some editors.
.s-why.s-why-last
:marked
**Why?** A component file's logic is easier to read when not mixed with inline template and styles.
+makeExample('style-guide/ts/05-04/app/heroes/heroes.component.avoid.ts', 'example', 'app/heroes/heroes.component.ts')(avoid=1)
:marked
+makeTabs(
`style-guide/ts/05-04/app/heroes/heroes.component.ts,
style-guide/ts/05-04/app/heroes/heroes.component.html,
style-guide/ts/05-04/app/heroes/heroes.component.css`,
'example,,',
`app/heroes/heroes.component.ts,
app/heroes/heroes.component.html,
app/heroes/heroes.component.css`)
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Decorate Input and Output Properties Inline
<a id="05-12"></a>
#### Style 05-12
.s-rule.do
:marked
**Do** use [`@Input`](https://angular.io/docs/ts/latest/api/core/Input-var.html) and [`@Output`](https://angular.io/docs/ts/latest/api/core/Output-var.html) instead of the `inputs` and `outputs` properties of the [`@Directive`](https://angular.io/docs/ts/latest/api/core/Directive-decorator.html) and [`@Component`](https://angular.io/docs/ts/latest/api/core/Component-decorator.html) decorators:
.s-rule.do
:marked
**Do** place the `@Input()` or `@Output()` on the same line as the property they decorate.
.s-why
:marked
**Why?** It is easier and more readable to identify which properties in a class are inputs or outputs.
.s-why
:marked
**Why?** If we ever need to rename the property or event name associated to [`@Input`](https://angular.io/docs/ts/latest/api/core/Input-var.html) or [`@Output`](https://angular.io/docs/ts/latest/api/core/Output-var.html) we can modify it on a single place.
.s-why
:marked
**Why?** The metadata declaration attached to the directive is shorter and thus more readable.
.s-why.s-why-last
:marked
**Why?** Placing the decorator on the same line makes for shorter code and still easily identifies the property as an input or output.
+makeExample('style-guide/ts/05-12/app/heroes/shared/hero-button/hero-button.component.avoid.ts', 'example', 'app/heroes/shared/hero-button/hero-button.component.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/05-12/app/heroes/shared/hero-button/hero-button.component.ts', 'example', 'app/heroes/shared/hero-button/hero-button.component.ts')
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Avoid Renaming Inputs and Outputs
<a id="05-13"></a>
#### Style 05-13
.s-rule.avoid
:marked
**Avoid** renaming inputs and outputs, when possible.
.s-why.s-why-last
:marked
**Why?** May lead to confusion when the output or the input properties of a given directive are named a given way but exported differently as a public API.
+makeExample('style-guide/ts/05-13/app/heroes/shared/hero-button/hero-button.component.avoid.ts', 'example', 'app/heroes/shared/hero-button/hero-button.component.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/05-13/app/app.component.avoid.html', '', 'app/app.component.html')(avoid=1)
:marked
+makeTabs(
`style-guide/ts/05-13/app/heroes/shared/hero-button/hero-button.component.ts,
style-guide/ts/05-13/app/app.component.html`,
'example,',
`app/heroes/shared/hero-button/hero-button.component.ts,
app/app.component.html`)
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Member Sequence
<a id="05-14"></a>
#### Style 05-14
.s-rule.do
:marked
**Do** place properties up top followed by methods.
.s-rule.do
:marked
**Do** place private members after public members, alphabetized.
.s-why.s-why-last
:marked
**Why?** Placing members in a consistent sequence makes it easy to read and helps we instantly identify which members of the component serve which purpose.
+makeExample('style-guide/ts/05-14/app/shared/toast/toast.component.avoid.ts', 'example', 'app/shared/toast/toast.component.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/05-14/app/shared/toast/toast.component.ts', 'example', 'app/shared/toast/toast.component.ts')
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Put Logic in Services
<a id="05-15"></a>
#### Style 05-15
.s-rule.do
:marked
**Do** limit logic in a component to only that required for the view. All other logic should be delegated to services.
.s-rule.do
:marked
**Do** move reusable logic to services and keep components simple and focused on their intended purpose.
.s-why
:marked
**Why?** Logic may be reused by multiple components when placed within a service and exposed via a function.
.s-why
:marked
**Why?** Logic in a service can more easily be isolated in a unit test, while the calling logic in the component can be easily mocked.
.s-why
:marked
**Why?** Removes dependencies and hides implementation details from the component.
.s-why.s-why-last
:marked
**Why?** Keeps the component slim, trim, and focused.
+makeExample('style-guide/ts/05-15/app/heroes/hero-list/hero-list.component.avoid.ts', '', 'app/heroes/hero-list/hero-list.component.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/05-15/app/heroes/hero-list/hero-list.component.ts', 'example', 'app/heroes/hero-list/hero-list.component.ts')
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Don't Prefix Output Properties
<a id="05-16"></a>
#### Style 05-16
.s-rule.do
:marked
**Do** name events without the prefix `on`.
.s-rule.do
:marked
**Do** name our event handler methods with the prefix `on` followed by the event name.
.s-why
:marked
**Why?** This is consistent with built-in events such as button clicks.
.s-why.s-why-last
:marked
**Why?** Angular allows for an [alternative syntax](https://angular.io/docs/ts/latest/guide/template-syntax.html#!#binding-syntax) `on-*`. If the event itself was prefixed with `on` this would result in an `on-onEvent` binding expression.
+makeExample('style-guide/ts/05-16/app/heroes/hero.component.avoid.ts', 'example', 'app/heroes/hero.component.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/05-16/app/app.component.avoid.html', '', 'app/app.component.html')(avoid=1)
:marked
+makeTabs(
`style-guide/ts/05-16/app/heroes/hero.component.ts,
style-guide/ts/05-16/app/app.component.html`,
'example,',
`app/heroes/hero.component.ts,
app/app.component.html`)
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Put Presentation Logic in the Component Class
<a id="05-17"></a>
#### Style 05-17
.s-rule.do
:marked
**Do** put presentation logic in the Component class, and not in the template.
.s-why
:marked
**Why?** Logic will be contained in one place (the Component class) instead of being spread in two places.
.s-why.s-why-last
:marked
**Why?** Keeping the component's presentation logic in the class instead of the template improves testability, maintainability, and reusability.
+makeExample('style-guide/ts/05-17/app/heroes/hero-list/hero-list.component.avoid.ts', 'example', 'app/heroes/hero-list/hero-list.component.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/05-17/app/heroes/hero-list/hero-list.component.ts', 'example', 'app/heroes/hero-list/hero-list.component.ts')
:marked
a(href="#toc") Back to top
.l-main-section
:marked
## Directives
a(href="#toc") Back to top
.l-main-section
:marked
### Use Directives to Enhance an Existing Element
<a id="06-01"></a>
#### Style 06-01
.s-rule.do
:marked
**Do** use attribute directives when you have presentation logic without a template.
.s-why
:marked
**Why?** Attributes directives don't have an associated template.
.s-why.s-why-last
:marked
**Why?** An element may have more than one attribute directive applied.
+makeExample('style-guide/ts/06-01/app/shared/highlight.directive.ts', 'example', 'app/shared/highlight.directive.ts')
:marked
+makeExample('style-guide/ts/06-01/app/app.component.html', null, 'app/app.component.html')
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Use HostListener and HostBinding Class Decorators
<a id="06-03"></a>
#### Style 06-03
.s-rule.do
:marked
**Do** use @HostListener and @HostBinding instead of the host property of the @Directive and @Component decorators:
.s-why
:marked
**Why?** The property or method name associated with @HostBinding or respectively @HostListener should be modified only in a single place - in the directive's class. In contrast if we use host we need to modify both the property declaration inside the controller, and the metadata associated to the directive.
.s-why.s-why-last
:marked
**Why?** The metadata declaration attached to the directive is shorter and thus more readable.
+makeExample('style-guide/ts/06-03/app/shared/validate.directive.avoid.ts', 'example', 'app/shared/validate.directive.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/06-03/app/shared/validate.directive.ts', 'example', 'app/shared/validate.directive.ts')
:marked
a(href="#toc") Back to top
.l-main-section
:marked
## Services
### Services are Singletons in Same Injector
<a id="07-01"></a>
#### Style 07-01
.s-rule.do
:marked
**Do** use services as singletons within the same injector. Use them for sharing data and functionality.
.s-why
:marked
**Why?** Services are ideal for sharing methods across a feature area or an app.
.s-why.s-why-last
:marked
**Why?** Services are ideal for sharing stateful in-memory data.
+makeExample('style-guide/ts/07-01/app/heroes/shared/hero.service.ts', 'example', 'app/heroes/shared/hero.service.ts')
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Single Responsibility
<a id="07-02"></a>
#### Style 07-02
.s-rule.do
:marked
**Do** create services with a single responsibility that is encapsulated by its context.
.s-rule.do
:marked
**Do** create a new service once the service begins to exceed that singular purpose.
.s-why
:marked
**Why?** When a service has multiple responsibilities, it becomes difficult to test.
.s-why.s-why-last
:marked
**Why?** When a service has multiple responsibilities, every Component or Service that injects it now carries the weight of them all.
a(href="#toc") Back to top
.l-main-section
:marked
### Providing a Service
<a id="07-03"></a>
#### Style 07-03
.s-rule.do
:marked
**Do** provide services to the Angular 2 injector at the top-most component where they will be shared.
.s-why
:marked
**Why?** The Angular 2 injector is hierarchical.
.s-why
:marked
**Why?** When providing the service to a top level component, that instance is shared and available to all child components of that top level component.
.s-why
:marked
**Why?** This is ideal when a service is sharing methods or state.
.s-why.s-why-last
:marked
**Why?** This is not ideal when two different components need different instances of a service. In this scenario it would be better to provide the service at the component level that needs the new and separate instance.
+makeTabs(
`style-guide/ts/07-03/app/app.component.ts,
style-guide/ts/07-03/app/heroes/hero-list/hero-list.component.ts`,
'',
`app/app.component.ts,
app/heroes/hero-list/hero-list.component.ts`)
:marked
a(href="#toc") Back to top
.l-main-section
:marked
### Use the @Injectable() Class Decorator
<a id="07-04"></a>
#### Style 07-04
.s-rule.do
:marked
**Do** use the `@Injectable` class decorator instead of the `@Inject` parameter decorator when using types as tokens for the dependencies of a service.
.s-why
:marked
**Why?** The Angular DI mechanism resolves all the dependencies of our services based on their types declared with the services' constructors.
.s-why.s-why-last
:marked
**Why?** When a service accepts only dependencies associated with type tokens, the `@Injectable()` syntax is much less verbose compared to using `@Inject()` on each individual constructor parameter.
+makeExample('style-guide/ts/07-04/app/heroes/shared/hero-arena.service.avoid.ts', 'example', 'app/heroes/shared/hero-arena.service.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/07-04/app/heroes/shared/hero-arena.service.ts', 'example', 'app/heroes/shared/hero-arena.service.ts')
:marked
a(href="#toc") Back to top
.l-main-section
:marked
## Data Services
### Separate Data Calls
<a id="08-01"></a>
#### Style 08-01
.s-rule.do
:marked
**Do** refactor logic for making data operations and interacting with data to a service.
.s-rule.do
:marked
**Do** make data services responsible for XHR calls, local storage, stashing in memory, or any other data operations.
.s-why
:marked
**Why?** The component's responsibility is for the presentation and gathering of information for the view. It should not care how it gets the data, just that it knows who to ask for it. Separating the data services moves the logic on how to get it to the data service, and lets the component be simpler and more focused on the view.
.s-why
:marked
**Why?** This makes it easier to test (mock or real) the data calls when testing a component that uses a data service.
.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.
a(href="#toc") Back to top
.l-main-section
:marked
## Lifecycle Hooks
Use Lifecycle Hooks to tap into important events exposed by Angular.
a(href="#toc") Back to top
.l-main-section
:marked
### Implement Lifecycle Hooks Interfaces
<a id="09-01"></a>
#### Style 09-01
.s-rule.do
:marked
**Do** implement the lifecycle hook interfaces.
.s-why.s-why-last
:marked
**Why?** We avoid unintentionally not calling the hook if we misspell the method.
+makeExample('style-guide/ts/09-01/app/heroes/shared/hero-button/hero-button.component.avoid.ts', 'example', 'app/heroes/shared/hero-button/hero-button.component.ts')(avoid=1)
:marked
+makeExample('style-guide/ts/09-01/app/heroes/shared/hero-button/hero-button.component.ts', 'example', 'app/heroes/shared/hero-button/hero-button.component.ts')
:marked
a(href="#toc") Back to top
.l-main-section
:marked
## Routing
Client-side routing is important for creating a navigation flow between a component tree hierarchy, and composing components that are made of many other child components.
a(href="#toc") Back to top
.l-main-section
:marked
### Component Router
<a id="10-01"></a>
#### Style 10-01
.s-rule.do
:marked
**Do** separate route configuration into a routing component file, also known as a component router.
.s-rule.do
:marked
**Do** use a `<router-outlet>` in the component router, where the routes will have their component targets display their templates.
.s-rule.do
:marked
**Do** focus the logic in the component router to the routing aspects and its target components.
.s-rule.do
:marked
**Do** extract other logic to services and other components.
.s-why
:marked
**Why?** A component that handles routing is known as the component router, thus this follows the Angular 2 routing pattern.
.s-why
:marked
**Why?** A component that handles routing is known as the componenter router.
.s-why.s-why-last
:marked
**Why?** The `<router-outlet>` indicates where the template should be displayed for the target route.
+makeExample('style-guide/ts/10-01/app/app.component.ts', '', 'app/app.component.ts')
:marked
a(href="#toc") Back to top
.l-main-section
:marked
## Appendix
Useful tools and tips for Angular 2.
a(href="#toc") Back to top
.l-main-section
:marked
### Codelyzer
<a id="A-01"></a>
#### Style A-01
.s-rule.do
:marked
**Do** use [codelyzer](https://www.npmjs.com/package/codelyzer) to follow this guide.
.s-rule.consider
:marked
**Consider** adjusting the rules in codelyzer to suit your needs.
a(href="#toc") Back to top
.l-main-section
:marked
### File Templates and Snippets
<a id="A-02"></a>
#### Style A-02
.s-rule.do
:marked
**Do** use file templates or snippets to help follow consistent styles and patterns. Here are templates and/or snippets for some of the web development editors and IDEs.
.s-rule.consider
:marked
**Consider** using [snippets](https://marketplace.visualstudio.com/items?itemName=johnpapa.Angular2) for [Visual Studio Code](https://code.visualstudio.com/) that follow these styles and guidelines.
:marked
[![Use Extension](https://github.com/johnpapa/vscode-angular2-snippets/raw/master/images/use-extension.gif)](https://marketplace.visualstudio.com/items?itemName=johnpapa.Angular2)
a(href="#toc") Back to top
Reference in New Issue View Git Blame Copy Permalink