From 4ca4a0a9f6072d72364bfab539ce3f582861f2cb Mon Sep 17 00:00:00 2001 From: Yang Lin Date: Tue, 29 Nov 2016 19:02:21 +0800 Subject: [PATCH 1/3] Polish style-guild.jade --- public/docs/ts/latest/guide/_data.json | 59 +- public/docs/ts/latest/guide/style-guide.jade | 757 ++++++++++++------- public/translate/cn/translate.js | 2 +- 3 files changed, 493 insertions(+), 325 deletions(-) diff --git a/public/docs/ts/latest/guide/_data.json b/public/docs/ts/latest/guide/_data.json index 871df28dcb..de3a9e03bc 100644 --- a/public/docs/ts/latest/guide/_data.json +++ b/public/docs/ts/latest/guide/_data.json @@ -28,44 +28,43 @@ "architecture": { "title": "架构概览", "navTitle": "架构", - "intro": "Angular应用的基本构造块", + "intro": "Angular 应用的基本构造块", "nextable": true, "basics": true }, - "appmodule": { "title": "AppModule: 根模块", "navTitle": "根模块", - "intro": "如何在根\"AppModule\"中构建和启动应用。", + "intro": "如何在根 \"AppModule\" 中构建和启动应用。", "nextable": true, "basics": true }, "displaying-data": { "title": "显示数据", - "intro": "属性绑定机制把数据显示到UI上。", + "intro": "属性绑定机制把数据显示到用户界面上。", "nextable": true, "basics": true }, "user-input": { "title": "用户输入", - "intro": "用户输入触发DOM事件。我们通过事件绑定来监听它们，把更新过的数据导入回我们的组件和model。", + "intro": "用户输入触发 DOM 事件。我们通过事件绑定来监听它们，把更新过的数据导入回我们的组件和 model。", "nextable": true, "basics": true }, "forms": { "title": "表单", - "intro": "表单创建一个有机、有效、引人注目的数据输入体验。Angular表单协调一组数据绑定控件，跟踪变更，验证输入的有效性，并且显示错误信息。", + "intro": "表单创建一个有机、有效、引人注目的数据输入体验。Angular 表单协调一组数据绑定控件，跟踪变更，验证输入的有效性，并且显示错误信息。", "nextable": true, "basics": true }, "dependency-injection": { "title": "依赖注入", - "intro": "Angular的依赖注入系统能够JIT(刚好及时)的创建和交付所依赖的服务。", + "intro": "Angular 的依赖注入系统能够即时地创建和交付所依赖的服务。", "nextable": true, "basics": true }, @@ -78,21 +77,21 @@ }, "cheatsheet": { - "title": "Angular小抄", - "intro": "一份Angular语法的快速指南", + "title": "Angular 速查表", + "intro": "一份 Angular 语法的快速指南", "nextable": true, "basics": true }, "style-guide": { "title": "风格指南", - "intro": "如何写Angular风格的程序", + "intro": "如何写 Angular 风格的程序", "basics": true }, "glossary": { "title": "词汇表", - "intro": "Angular中最重要的词汇的简要定义", + "intro": "Angular 中最重要的词汇的简要定义", "basics": true }, @@ -103,13 +102,13 @@ }, "ngmodule": { - "title": "Angular模块（NgModule）", + "title": "Angular模块 (NgModule)", "intro": "用@NgModule定义应用中的模块" }, "animations": { "title": "动画", - "intro": "Angular动画系统指南。" + "intro": "Angular 动画系统指南。" }, "attribute-directives": { @@ -119,12 +118,12 @@ "browser-support": { "title": "浏览器支持", - "intro": "浏览器支持与填充（Polyfill）指南" + "intro": "浏览器支持与填充 (Polyfill) 指南" }, "component-styles": { "title": "组件样式", - "intro": "学习如何给组件应用CSS样式。" + "intro": "学习如何给组件应用 CSS 样式。" }, "hierarchical-dependency-injection": { @@ -134,18 +133,18 @@ }, "server-communication": { - "title": "HTTP客户端", - "intro": "通过HTTP客户端与远程服务器对话。" + "title": "HTTP 客户端", + "intro": "通过 HTTP 客户端与远程服务器对话。" }, "lifecycle-hooks": { "title": "生命周期钩子", - "intro": "Angular调用指令和组件的生命周期钩子函数，包括它的创建、变更和销毁时。" + "intro": "Angular 调用指令和组件的生命周期钩子函数，包括它的创建、变更和销毁时。" }, "npm-packages": { - "title": "Npm包", - "intro": "推荐的npm包以及如何指定所依赖的包" + "title": "npm 包", + "intro": "推荐的 npm 包以及如何指定所依赖的包" }, "pipes": { @@ -155,12 +154,12 @@ "router": { "title": "路由与导航", - "intro": "揭示如何通过Angular路由进行基本的屏幕导航。" + "intro": "揭示如何通过 Angular 路由进行基本的屏幕导航。" }, "security": { "title": "安全", - "intro": "开发“内容安全”的Angular应用。" + "intro": "开发内容安全的 Angular 应用。" }, "setup-systemjs-anatomy": { @@ -170,26 +169,26 @@ "structural-directives": { "title": "结构型指令", - "intro": "Angular有一个强力的模板引擎，它能让你轻松维护元素的DOM树结构。" + "intro": "Angular 有一个强力的模板引擎，它能让你轻松维护元素的DOM树结构。" }, "testing": { "title": "测试", - "intro": "Angular应用的测试技术与实践。" + "intro": "Angular 应用的测试技术与实践。" }, "typescript-configuration": { - "title": "TypeScript配置", - "intro": "Angular开发者的TypeScript配置" + "title": "TypeScript 配置", + "intro": "Angular 开发者的 TypeScript 配置" }, "upgrade": { - "title": "从1.x升级", - "intro": "Angular 1应用可以逐步升级到Angular 2。" + "title": "从 1.x 升级", + "intro": "Angular 1 应用可以逐步升级到 Angular 2。" }, "webpack": { - "title": "Webpack简介", - "intro": "使用基于Webpack的工具创建Angular应用" + "title": "Webpack 简介", + "intro": "使用基于 Webpack 的工具创建 Angular 应用" } } diff --git a/public/docs/ts/latest/guide/style-guide.jade b/public/docs/ts/latest/guide/style-guide.jade index 6514b1be28..d08d8aeedd 100644 --- a/public/docs/ts/latest/guide/style-guide.jade +++ b/public/docs/ts/latest/guide/style-guide.jade @@ -3,31 +3,33 @@ include ../_util-fns :marked Welcome to the Angular Style Guide - 欢迎光临Angular风格指南 + 欢迎光临 Angular 风格指南 ## Purpose + ## 目的 Looking for an opinionated guide to Angular syntax, conventions, and application structure? Step right in! This style guide presents our preferred conventions and, as importantly, explains why. - 如果你在寻找一份关于语法、约定和Angular应用程序的组织结构的风格指南，那你就来对了。 - 本风格指南提供了我们所提倡的约定，但最重要的是，解释了为什么。 + 如果你正在寻找关于 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 @@ -36,7 +38,9 @@ include ../_util-fns Guidelines that literally should always be followed are extremely rare. On the other hand, you need a really unusual case for breaking a *Do* guideline. - **坚持**意味着总是应该遵循的约定。_总是_可能有点太强。应该_总是_遵循的指导原则非常少见。但是，只有遇到非常不寻常的情况才能打破*坚持*的原则。 + **坚持**意味着总是应该遵循的约定。 + _总是_可能有点太强了。应该_总是_遵循的指导原则非常少。 + 但是，只有遇到非常不寻常的情况才能打破*坚持*的原则。 .s-rule.consider :marked @@ -46,99 +50,107 @@ include ../_util-fns 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 you 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)。 + 在一些代码例子中，有的文件有一个或多个相似名字的伴随文件。（例如 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`的简写来表示上面描述的多个文件，目的是保持本指南的简洁性，增加文件结构描述时的可读性。 + 本指南将会使用像`hero.component.ts|html|css|spec`的简写来表示上面描述的多个文件，目的是保持本指南的简洁性，增加描述文件结构时的可读性。 .l-main-section a(id='toc') :marked ## Table of Contents + ## 目录 1. [Single Responsibility](#single-responsibility) - 1. [单一职责](#single-responsibility) + [单一职责](#single-responsibility) 1. [Naming](#naming) - 1. [命名约定](#naming) + [命名](#naming) 1. [Coding Conventions](#coding-conventions) - 1. [代码约定](#coding-conventions) + [代码约定](#coding-conventions) 1. [App Structure and Angular Modules](#app-structure-and-angular-modules) - 1. [应用程序结构与模块划分](#app-structure-and-angular-modules) + [应用结构与 Angular 模块](#app-structure-and-angular-modules) 1. [Components](#components) - 1. [组件](#components) + [组件](#components) 1. [Directives](#directives) - 1. [指令](#directives) + [指令](#directives) 1. [Services](#services) - 1. [服务](#services) + [服务](#services) 1. [Data Services](#data-services) - 1. [数据服务](#data-services) + [数据服务](#data-services) 1. [Lifecycle Hooks](#lifecycle-hooks) - 1. [生命周期钩子](#lifecycle-hooks) + [生命周期钩子](#lifecycle-hooks) 1. [Appendix](#appendix) - 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. This helps make the app cleaner, easier to read and maintain, and more testable. - 我们遵循[单一职责原则](https://en.wikipedia.org/wiki/Single_responsibility_principle)来创建的所有组件、服务和其它标志等。这样能帮助我们把应用程序弄的干净整洁，易于阅读、维护和测试。 + 所有组件、服务和其它符号都要遵循[单一职责原则](https://en.wikipedia.org/wiki/Single_responsibility_principle。 + 这会使应用程序更干净，易于阅读和维护，提高可测试性。 ### Rule of One + ### 单一法则 + #### 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行代码以内。 + **考虑**把文件大小限制在 400 行代码以内。 .s-why :marked @@ -156,7 +168,7 @@ a(id='toc') :marked **Why?** A single component can be the default export for its file which facilitates lazy loading with the Router. - **为何？**单独的组件通常是该文件默认的输出，这样就可以利用路由器实现按需加载。 + **为何？**单独的组件通常是该文件默认的导出，可以用路由器实现按需加载。 :marked The key is to make the code more reusable, easier to read, and less mistake prone. @@ -165,13 +177,13 @@ a(id='toc') 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`模型对象，并且从服务器加载了英雄 ... 所有都在发生在同一个文件。 *不要这么做*。 + 下面的*负面*例子定义了`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/main.ts, @@ -202,9 +214,13 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Small Functions + ### 小函数 + #### Style 01-02 - #### 风格01-02 + + #### 风格 01-02 + .s-rule.do :marked **Do** define small functions @@ -215,36 +231,36 @@ a(href="#toc").to-top 回到顶部 :marked **Consider** limiting to no more than 75 lines. - **考虑**限制在75行之内 + **考虑**限制在 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").to-top Back to top @@ -253,24 +269,28 @@ a(href="#toc").to-top 回到顶部 .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 - ### 总体命名知道原则 + + ### 总体命名指导原则 + #### Style 02-01 - #### 风格02-01 + + #### 风格 02-01 .s-rule.do :marked **Do** use consistent names for all symbols. - **坚持**为所有符号使用一致的命名规则。 + **坚持**所有符号使用一致的命名规则。 .s-rule.do :marked @@ -282,19 +302,21 @@ a(href="#toc").to-top 回到顶部 :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 find desited 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`包含了一个用来维护英雄列表的组件。 + **为何？**目录名和文件名应该清楚的传递它们的意图。 + 例如，`app/heroes/hero-list.component.ts`包含了一个用来管理英雄列表的组件。 a(href="#toc").to-top Back to top @@ -303,61 +325,64 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Separate File Names with Dots and Dashes + ### 使用点和横杠来分隔文件名 + #### Style 02-02 - #### 风格02-02 + + #### 风格 02-02 .s-rule.do :marked **Do** use dashes to separate words in the descriptive name. - **坚持** 在描述性名字里面，使用横杠来分隔单词。 + **坚持** 在描述性名字中，用横杠来分隔单词。 .s-rule.do :marked **Do** use dots to separate the descriptive name from the type. - **坚持**使用点来分隔描述性名字和类型名。 + **坚持**使用点来分隔描述性名字和类型。 .s-rule.do :marked **Do** use consistent type 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`。 + **坚持**遵循先描述组件特性，再描述它的类型的模式，对所有组件使用一致的类型命名规则。推荐的模式为`feature.type.ts`。 .s-rule.do :marked **Do** use conventional type names including `.service`, `.component`, `.pipe`, `.module`, `.directive`. Invent additional type names if you must but take care not to create too many. - **坚持**使用惯用的后缀来描述类型，比如`*.service`、`*.component`、`*.pipe`、`.module`、`.directive`。 - 创建更多类型名，但你必须注意不要创建太多。 + **坚持**使用惯用的后缀来描述类型，包括`*.service`、`*.component`、`*.pipe`、`.module`、`.directive`。 + 必要时可以创建更多类型名，但必须注意，不要创建太多。 .s-why :marked **Why?** Type names provide a consistent way to quickly identify what is in the file. - **为何？**类型名字提供一致的方法来快速的识别文件是什么。 + **为何？**类型名字提供一致的方式来快速的识别文件中有什么。 .s-why :marked **Why?** Make it easy to find a specific file type using an editor or IDE's fuzzy search techniques. - **为何？** 可以让我们利用编辑器或者IDE的模糊搜索功能，很容易的找到特定文件。 + **为何？** 利用编辑器或者 IDE 的模糊搜索功能，可以很容易地找到特定文件。 .s-why :marked **Why?** Unabbreviated type names such as `.service` are descriptive and unambiguous. Abbreviations such as `.srv`, `.svc`, and `.serv` can be confusing. - **为何？** 没有被简写的类型名字比如`.service`很有描述性，不含糊。 - 简写可能造成混淆，比如`.srv`, `.svc`, 和 `.serv`。 + **为何？** 象`.service`这样的没有简写过的类型名字，描述清楚，毫不含糊。 + 像`.srv`, `.svc`, 和 `.serv`这样的简写可能令人困惑。 .s-why.s-why-last :marked **Why?** Provides pattern matching for any automated tasks. - **为何？**与自动化任务的模式匹配。 + **为何？**为自动化任务提供模式匹配。 a(href="#toc").to-top Back to top @@ -366,46 +391,49 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Symbols and File Names + ### 符号名与文件名 + #### Style 02-03 - #### 风格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 class names. Match the name of the symbol to the name of the file. - **坚持**使用大写驼峰命名法来命名所有类名。保持符号的名字与它所在的文件名字相同。 + **坚持**使用大写驼峰命名法来命名类。符号名匹配它所在的文件名。 .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`). - **坚持**在符号名后面追加约定的类型后缀（比如：`Component`、`Directive`、`Module`、`Pipe`、`Service`）。 + **坚持**在符号名后面追加约定的类型后缀（如`Component`、`Directive`、`Module`、`Pipe`、`Service`）。 .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`). - **坚持**在文件名后面追加约定的类型后缀（比如`.component.ts`、`.directive.ts`、`.module.ts`、`.pipe.ts`、`.service.ts`）。 + **坚持**在文件名后面追加约定的类型后缀（如`.component.ts`、`.directive.ts`、`.module.ts`、`.pipe.ts`、`.service.ts`）。 .s-why :marked **Why?** Provides a consistent way to quickly identify and reference assets. - **为何？**提供一种一致的方式，以快速标识和引用资产。 + **为何？**提供一致的方式来快速标识和引用资产。 .s-why.s-why-last :marked **Why?** Upper camel case is conventional for identifying objects that can be instantiated using a constructor. - **为何？**大驼峰命名法是用来识别那些能通过构造函数进行实例化的对象的命名约定。 + **为何？**大驼峰命名法用于标识可以通过构造函数实例化的对象。 - var top="vertical-align:top" table(width="100%") @@ -491,45 +519,48 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Service Names + ### 服务名 + #### Style 02-04 - #### 风格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`后缀。 + **坚持**添加`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`不需要后缀。 + **为何？**象`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`，需要一个后缀。当名字不能很明显的标示出它是服务还是其它东西的时候，应该添加后缀。 + **为何？**像`Credit`这样的，服务名是名词，需要一个后缀。当不能明显分辨它是服务还是其它东西时，应该添加后缀。 - var top="vertical-align:top" table(width="100%") @@ -575,9 +606,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Bootstrapping + ### 引导 + #### Style 02-05 - #### 风格02-05 + + #### 风格 02-05 .s-rule.do :marked @@ -589,25 +623,25 @@ a(href="#toc").to-top 回到顶部 :marked **Do** include error handling in the bootstrapping logic. - **坚持**在“引导”逻辑中包含错误处理代码。 + **坚持**在引导逻辑中包含错误处理代码。 .s-rule.avoid :marked **Avoid** putting app logic in the `main.ts`. Instead consider placing it in a component or service. - **避免**把应用逻辑放在`main.ts`中，而应该考虑把它们放进组件或服务里。 + **避免**把应用逻辑放在`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. - **为何？**这是从其它技术平台借鉴的一个常用约定。 + **为何？**这是从其它技术平台借鉴的常用约定。 +makeExample('style-guide/ts/02-05/main.ts', '', 'main.ts') :marked @@ -619,9 +653,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Directive Selectors - ### 指令的选择器 + + ### 指令选择器 + #### Style 02-06 - #### 风格02-06 + + #### 风格 02-06 .s-rule.do :marked @@ -633,13 +670,13 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** Keeps the names of the properties defined in the directives that are bound to the view consistent with the attribute names. - **为何？**保持指令里定义的属性名字与它们绑定的视图HTML属性名字一致。 + **为何？**保持指令中定义的属性名与绑定的视图 HTML 属性名字一致。 .s-why.s-why-last :marked **Why?** The Angular HTML parser is case sensitive and will recognize lower camel case. - **为何？**Angular HTML解析器是大小写敏感的，它识别小写驼峰写法。 + **为何？**Angular HTML 解析器是大小写敏感的，它识别小写驼峰写法。 a(href="#toc").to-top Back to top @@ -648,47 +685,50 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Custom Prefix for Components - ### 为组件自定义前缀 + + ### 为组件添加自定义前缀 + #### Style 02-07 - #### 风格02-07 + + #### 风格 02-07 .s-rule.do :marked **Do** use a hyphenated, lowercase element selector value (e.g. `admin-users`). - **坚持**使用带连字符的小写元素选择器的值（比如`admin-users`）。 + **坚持**使用带连字符的小写元素选择器值（比如`admin-users`）。 .s-rule.do :marked **Do** use a custom prefix for a component selector. For example, the prefix `toh` represents from **T**our **o**f **H**eroes and the prefix `admin` represents an admin feature area. - **坚持**为组件选择器使用自定义前缀。 - 比如`toh`前缀表示**T**our **o**f **H**eroes（英雄指南），而前缀`admin表示管理特性区。 + **坚持**为组件选择器添加自定义前缀。 + 例如，`toh`前缀表示 **T**our **o**f **H**eroes（英雄指南），而前缀`admin表示管理特性区。 .s-rule.do :marked **Do** use a prefix that identifies the feature area or the app itself. - **坚持**使用前缀来识别特性区域或者应用程序本身。 + **坚持**使用前缀来识别特性区或者应用程序本身。 .s-why :marked **Why?** Prevents element name collisions with components in other apps and with native HTML elements. - **为何？**防止与来自其它应用中的组件和原生HTML元素发生命名冲突。 + **为何？**防止与其它应用中的组件和原生 HTML 元素发生命名冲突。 .s-why :marked **Why?** Makes it easier to promote and share the component in other apps. - **为何？**把我们的组件推广和共享到其它应用中会更容易。 + **为何？**更容易在其它应用中推广和共享组件。 .s-why.s-why-last :marked **Why?** Components are easy to identify in the DOM. - **为何？**组件在DOM中更容易被区分出来。 + **为何？**组件在 DOM 中更容易被区分出来。 +makeExample('style-guide/ts/02-07/app/heroes/hero.component.avoid.ts', 'example', 'app/heroes/hero.component.ts')(avoid=1) :marked @@ -704,21 +744,24 @@ a(href="#toc").to-top 回到顶部 :marked ### Custom Prefix for Directives + ### 为指令添加自定义前缀 + #### Style 02-08 - #### 风格02-08 + + #### 风格 02-08 .s-rule.do :marked **Do** use a custom prefix for the selector of directives (e.g, the prefix `toh` from **T**our **o**f **H**eroes). - **坚持**为指令的选择器使用自定义前缀（比如前缀`toh`来自**T**our **o**f **H**eroes）。 + **坚持**为指令的选择器添加自定义前缀（比如前缀`toh`来自**T**our **o**f **H**eroes）。 .s-rule.do :marked **Do** spell non-element selectors in lower camel case unless the selector is meant to match a native HTML attribute. - **坚持**用小驼峰形式拼写非元素选择器，除非该选择器就是要用来匹配某个原生HTML属性的。 + **坚持**用小驼峰形式拼写非元素选择器，除非该选择器用于匹配原生 HTML 属性。 .s-why :marked @@ -745,21 +788,24 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Pipe Names + ### 管道名 + #### Style 02-09 - #### 风格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%") @@ -797,33 +843,36 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Unit Test File Names + ### 单元测试文件名 + #### Style 02-10 - #### 风格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`。 + **坚持**测试规格文件名添加`.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/)或者其它测试运行器相配的命名模式。 + **为何？**提供一个与 [karma](http://karma-runner.github.io/) 或者其它测试运行器相配的命名模式。 :marked - var top="vertical-align:top" @@ -883,27 +932,30 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### End to End Test File Names + ### 端到端测试文件名 + #### Style 02-11 - #### 风格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`。 + **坚持**端到端测试规格文件和它们所测试的特性同名，添加`.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 @@ -938,15 +990,18 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Angular NgModule Names - ### Angular NgModule命名 + + ### Angular NgModule 命名 + #### Style 02-12 + #### 风格 02-12 .s-rule.do :marked **Do** append the symbol name with the suffix `Module`. - **坚持**为符号名追加`Module`后缀 + **坚持**为符号名添加`Module`后缀 .s-rule.do :marked @@ -964,39 +1019,39 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** Provides a consistent way to quickly identify and reference modules. - **为何？**提供一个一致的方式来快速的标出和引用模块。 + **为何？**提供一致的方式来快速标识和引用模块。 .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?** Easily identifies the module as the root of the same named feature. - **为何？**很容易就能看出这个模块是同名特性的跟模块。 + **为何？**很容易就能看出这个模块是同名特性的根模块。 .s-rule.do :marked **Do** suffix a _RoutingModule_ class name with `RoutingModule`. - **坚持**为*RoutingModule*类名添加`RoutingModule`后缀。 + **坚持**为 *RoutingModule* 类名添加`RoutingModule`后缀。 .s-rule.do :marked **Do** end the filename of a _RoutingModule_ with `-routing.module.ts`. - **坚持** *RoutingModule*的文件名用`-routing.module.ts`结尾。 + **坚持**为 *RoutingModule* 的文件名添加`-routing.module.ts`后缀。 .s-why.s-why-last :marked **Why?** A `RoutingModule` is a module dedicated exclusively to configuring the Angular router. A consistent class and file name convention make these modules easy to spot and verify. - **为何？**`RoutingModule`是一种专门用来配置Angular路由器的模块。 - “让类名和文件名保持一致”这项约定可以让这些模块易于跟踪和验证。 + **为何？**`RoutingModule`是一种专门用来配置 Angular 路由器的模块。 + “类名和文件名保持一致”的约定使这些模块易于发现和验证。 - var top="vertical-align:top" table(width="100%") @@ -1054,18 +1109,22 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ## Coding Conventions + ## 编程约定 Have consistent set of coding, naming, and whitespace conventions. - 坚持一套前后一致的编程、命名和空格的约定。 + 坚持一致的编程、命名和空格的约定。 .l-main-section :marked ### Class + ### 类 + #### Style 03-01 - #### 风格03-01 + + #### 风格 03-01 .s-rule.do :marked @@ -1084,7 +1143,7 @@ a(href="#toc").to-top 回到顶部 **Why?** Classes can be instantiated and construct an instance. By convention, upper camel case indicates a constructable asset. - **为何？**类可以被实例化和构造出实例。根据约定，用大写驼峰命名法来标示可被构造出来的东西。 + **为何？**类可以被实例化和构造实例。根据约定，用大写驼峰命名法来标识可构造的东西。 +makeExample('style-guide/ts/03-01/app/core/exception.service.avoid.ts', 'example', 'app/shared/exception.service.ts')(avoid=1) :marked @@ -1099,9 +1158,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Constants + ### 常量 + #### Style 03-02 - #### 风格03-02 + + #### 风格 03-02 .s-rule.do :marked @@ -1113,14 +1175,14 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** Conveys to readers that the value is invariant. - **为何？** 告诉读者这个值是不可变的。 + **为何？**告诉读者这个值是不可变的。 .s-why.s-why-last :marked **Why?** TypeScript helps enforce that intent by requiring immediate initialization and by preventing subsequent re-assignment. - **为何？**TypeScript会要求在声明时立即初始化，并阻止对其再次赋值，以确保达成我们的意图。 + **为何？** TypeScript 会要求在声明时立即初始化，并阻止再次赋值，以确保达成我们的意图。 .s-rule.consider :marked @@ -1133,7 +1195,7 @@ a(href="#toc").to-top 回到顶部 **Why?** lower camel case variable names (`heroRoutes`) are easier to read and understand than the traditional UPPER_SNAKE_CASE names (`HERO_ROUTES`). - **为何？**小驼峰变量名（`heroRoutes`）比传统的“大写蛇形命名法”（`HERO_ROUTES`）更容易阅读和理解。 + **为何？**小驼峰变量名 (`heroRoutes`) 比传统的大写蛇形命名法 (`HERO_ROUTES`) 更容易阅读和理解。 .s-why.s-why-last :marked @@ -1141,14 +1203,15 @@ a(href="#toc").to-top 回到顶部 an era before the modern IDEs that quickly reveal the `const` declaration. TypeScript itself prevents accidental reassignment. - **为何？** 把常量命名为大写蛇形命名法的传统源于现代IDE出现之前，以便阅读时可以快速发现那些`const`定义。 - 而TypeScript本身就能够防止意外赋值。 + **为何？** 把常量命名为大写蛇形命名法的传统源于现代 IDE 出现之前， + 以便阅读时可以快速发现那些`const`定义。 + TypeScript 本身就能够防止意外赋值。 .s-rule.do :marked **Do** tolerate _existing_ `const` variables that are spelled in UPPER_SNAKE_CASE. - **坚持** 容许_现存的_`const`变量沿用大写蛇形命名法。 + **坚持**容许_现存的_`const`常量沿用大写蛇形命名法。 .s-why.s-why-last :marked @@ -1156,8 +1219,8 @@ a(href="#toc").to-top 回到顶部 especially in third party modules. It is rarely worth the effort to change them or the risk of breaking existing code and documentation. - **为何？**传统的大写蛇形命名法（UPPER_SNAKE_CASE）仍然很流行、很普遍，特别是在第三方模块中。 - 修改它们带不来多大价值，同时还会有破坏现有代码和文档的风险。 + **为何？**传统的大写蛇形命名法仍然很流行、很普遍，特别是在第三方模块中。 + 修改它们没多大价值，还会有破坏现有代码和文档的风险。 +makeExample('style-guide/ts/03-02/app/core/data.service.ts', '', 'app/shared/data.service.ts') :marked @@ -1169,9 +1232,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Interfaces + ### 接口 + #### Style 03-03 - #### 风格03-03 + + #### 风格 03-03 .s-rule.do :marked @@ -1196,7 +1262,7 @@ a(href="#toc").to-top 回到顶部 **Why?** TypeScript guidelines discourage the "I" prefix. - **为何？**TypeScript指导原则不建议使用“I”前缀。 + **为何？**TypeScript 指导原则不建议使用 “I” 前缀。 .s-why :marked @@ -1208,13 +1274,13 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** A class can act as an interface (use `implements` instead of `extends`). - **为何？**类实际上就是接口（只是要用`implements`代替`extends`而已）。 + **为何？**类可以作为接口使用（只是用`implements`代替`extends`而已）。 .s-why.s-why-last :marked **Why?** An interface-class can be a provider lookup token in Angular dependency injection. - **为何？**在Angular依赖注入系统中，接口类可以作为服务提供商的查阅令牌。 + **为何？**在 Angular 依赖注入系统中，接口类可以作为服务提供商的查找令牌。 +makeExample('style-guide/ts/03-03/app/core/hero-collector.service.avoid.ts', 'example', 'app/shared/hero-collector.service.ts')(avoid=1) :marked @@ -1229,9 +1295,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Properties and Methods + ### 属性和方法 + #### Style 03-04 - #### 样式03-04 + + #### 样式 03-04 .s-rule.do :marked @@ -1243,7 +1312,7 @@ a(href="#toc").to-top 回到顶部 :marked **Avoid** prefixing private properties and methods with an underscore. - **避免**使用下划线为前缀来命名私有属性和方法。 + **避免**为私有属性和方法添加下划线前缀。 .s-why :marked @@ -1255,13 +1324,13 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** JavaScript lacks a true private property or method. - **为何？**JavaScript不支持真正的私有属性和方法。 + **为何？** JavaScript 不支持真正的私有属性和方法。 .s-why.s-why-last :marked **Why?** TypeScript tooling makes it easy to identify private vs public properties and methods. - **为何？**TypeScript工具让识别私有或公有属性和方法变得很简单。 + **为何？** TypeScript 工具让识别私有或公有属性和方法变得很简单。 +makeExample('style-guide/ts/03-04/app/core/toast.service.avoid.ts', 'example', 'app/shared/toast.service.ts')(avoid=1) :marked @@ -1275,15 +1344,18 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Import Line Spacing + ### 导入语句中的空行 + #### Style 03-06 - #### 风格03-06 + + #### 风格 03-06 .s-rule.consider :marked **Consider** leaving one empty line between third party imports and application imports. - **坚持**在第三方导入和自己代码的导入之间留一个空行。 + **坚持**在第三方导入和应用导入之间留一个空行。 .s-rule.consider :marked @@ -1301,7 +1373,7 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** The empty line makes it easy to read and locate imports. - **为何？**空行可以让阅读和定位本地导入变得更加容易。 + **为何？**空行可以让阅读和定位本地导入更加容易。 .s-why.s-why-last :marked @@ -1322,25 +1394,28 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ## App Structure and Angular Modules - ## 应用程序的结构与Angular模块划分 + + ## 应用程序结构与 Angular 模块 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 feature areas are in their own folder, with their own Angular module. - 把所有应用程序的源代码都放到名叫`app`的目录里。 - 所有特性区都在自己的文件夹中，带有他们自己的Angular模块。 + 所有应用程序的源代码都放到名叫`app`的目录里。 + 所有特性区都在自己的文件夹中，带有它们自己的 Angular 模块。 All content is 1 asset 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. You didn't write them and you don't want them cluttering app. Use the naming conventions for files in this guide. - 所有内容都遵循每个文件单个特性的原则。每个组件、服务和管道都在自己的文件里。 - 所有第三方程序包都被保存到其它目录里而不在`app`目录里，我们不会修改它们，所以不希望它们弄乱我们的应用程序。使用本指南介绍的文件命名约定。 + 所有内容都遵循每个文件一个特性的原则。每个组件、服务和管道都在自己的文件里。 + 所有第三方程序包保存到其它目录里，不是`app`目录。 + 你不会修改它们，所以不希望它们弄乱我们的应用程序。 + 使用本指南介绍的文件命名约定。 a(href="#toc").to-top Back to top @@ -1349,9 +1424,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### LIFT + ### LIFT + #### Style 04-01 - #### 风格04-01 + + #### 风格 04-01 .s-rule.do :marked @@ -1360,13 +1438,13 @@ a(href="#toc").to-top 回到顶部 keep the `F`lattest structure you can, and `T`ry to be DRY. - **坚持**组织应用的结构，达到这些目的：快速定位(`L`ocate)代码、一眼识别(`I`dentify)代码、尽量保持扁平结构(`F`lattest)和尝试`T`ry遵循不重复自己DRY - Do Not Repeat Yourself原则。 + **坚持**组织应用的结构，达到这些目的：快速定位 (`L`ocate) 代码、一眼识别 (`I`dentify) 代码、 尽量保持扁平结构 (`F`lattest) 和尝试 (`T`ry) 遵循DRY (Do Not Repeat Yourself, 不重复自己) 原则。 .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 @@ -1374,7 +1452,8 @@ a(href="#toc").to-top 回到顶部 To confirm your intuition about a particular structure, ask: _can I quickly open and start work in all of the related files for this feature_? - **为何？**LIFT提供了前后一致的结构，它具有扩展性强、模块化的特性。因为容易快速锁定代码，所以提高了开发者的效率。另外，检查应用结构是否合理的方法是问问自己：我们能快速打开与此特性有关的文件并开始工作吗？ + **为何？**LIFT提供了一致的结构，它具有扩展性强、模块化的特性。因为容易快速锁定代码，提高了开发者的效率。 + 另外，检查应用结构是否合理的方法是问问自己：我们能快速打开与此特性有关的所有文件并开始工作吗？ a(href="#toc").to-top Back to top a(href="#toc").to-top 回到顶部 @@ -1382,16 +1461,18 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Locate + ### 定位 #### Style 04-02 - #### 风格04-02 + + #### 风格04-02 .s-rule.do :marked **Do** make locating code intuitive, simple and fast. - **坚持**直观、简单和快速的定位我们的代码。 + **坚持**直观、简单和快速地定位代码。 .s-why.s-why-last :marked @@ -1413,27 +1494,30 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Identify + ### 识别 + #### Style 04-03 - #### 风格04-03 + + #### 风格 04-03 .s-rule.do :marked **Do** name the file such that you instantly know what it contains and represents. - **坚持**命名文件到这个程度：可以从名字立刻知道它包含了什么，代表了什么。 + **坚持**命名文件到这个程度：看到名字立刻知道它包含了什么，代表了什么。 .s-rule.do :marked **Do** be descriptive with file names and keep 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 @@ -1449,7 +1533,8 @@ a(href="#toc").to-top 回到顶部 you have a set of small, closely-related features that are better discovered and understood in a single file than as multiple files. Be wary of this loophole. - 当你有一组小型、紧密相关的特性时，违反*一物一文件*的规则可能会更好，这种情况下单一文件可能会比多个文件更容易发现和理解。注意这个例外。 + 当你有一组小型、紧密相关的特性时，违反*一物一文件*的规则可能会更好， + 这种情况下单一文件可能会比多个文件更容易发现和理解。注意这个例外。 a(href="#toc").to-top Back to top @@ -1458,9 +1543,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Flat + ### 扁平 + #### Style 04-04 - #### 风格04-04 + + #### 风格 04-04 .s-rule.do :marked @@ -1472,13 +1560,13 @@ a(href="#toc").to-top 回到顶部 :marked **Consider** creating sub-folders when a folder reaches seven or more files. - **考虑**当同一目录下达到7个或更多个文件时创建子目录。 + **考虑**当同一目录下达到 7 个或更多个文件时创建子目录。 .s-rule.consider :marked **Consider** configuring the IDE to hide distracting, irrelevant files such as generated `.js` and `.js.map` files. - **考虑**配置IDE，以隐藏无关的文件，比如生成出来的`.js`文件和`.js.map`文件等。 + **考虑**配置 IDE，以隐藏无关的文件，比如生成出来的`.js`文件和`.js.map`文件等。 s-why.s-why-last :marked @@ -1493,8 +1581,8 @@ s-why.s-why-last So when a folder has ten or more files, it may be time to create subfolders. 另一方面，心理学家们相信， - 当关注的事物超过9个时，人类就会开始感到吃力。 - 所以，当一个文件夹中有10个或更多个文件时，可能就是创建子目录的时候了。 + 当关注的事物超过 9 个时，人类就会开始感到吃力。 + 所以，当一个文件夹中的文件有 10 个或更多个文件时，可能就是创建子目录的时候了。 Base your decision on your comfort level. Use a flatter structure until there is an obvious value to creating a new folder. @@ -1509,21 +1597,24 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### T-DRY (Try to be DRY) - ### T-DRY (尝试遵循不重复自己DRY的约定) + + ### T-DRY （尝试不重复自己） + #### Style 04-05 - #### 风格04-05 + + #### 风格 04-05 .s-rule.do :marked **Do** be DRY (Don't Repeat Yourself) - **坚持**不要重复自己(DRY) + **坚持** DRY（Don't Repeat Yourself，不重复自己）。 .s-rule.avoid :marked **Avoid** being so DRY that you sacrifice readability. - **避免**过度DRY，以致牺牲了阅读性。 + **避免**过度 DRY，以致牺牲了阅读性。 .s-why.s-why-last :marked @@ -1532,10 +1623,10 @@ a(href="#toc").to-top 回到顶部 For example, it's redundant to name a component, `hero-view.component.html` because a component is obviously a view. But if something is not obvious or departs from a convention, then spell it out. - **为何？**虽然DRY（不要重复你自己）很重要，但如果要以牺牲LIFT的其它原则为代价，那就不值得了。 - 这也就是为什么它被称为*T-DRY*。 - 比如，把组件命名为`hero-view.component.html`是多余的，因为组件显然就是一个视图（view）。 - 但如果它不是这么显著，或不符合常规，那就把它写出来。 + **为何？**虽然 DRY 很重要，但如果要以牺牲 LIFT 的其它原则为代价，那就不值得了。 + 这也就是为什么它被称为 *T-DRY*。 + 比如，把组件命名为`hero-view.component.html`是多余的，因为组件显然就是一个视图 (view)。 + 但如果它不那么显著，或不符合常规，就把它写出来。 a(href="#toc").to-top Back to top @@ -1544,21 +1635,24 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Overall Structural Guidelines + ### 总体结构指导原则 + #### Style 04-06 - #### 风格04-06 + + #### 风格 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 @@ -1570,25 +1664,25 @@ a(href="#toc").to-top 回到顶部 :marked **Consider** creating a folder for a component when is has multiple accompanying files (`.ts`, `.html`, `.css` and `.spec`). - **坚持**如果组件具有多个相互合作的文件（`.ts`、`.html`、`.css`和`.spec`），那就为它创建一个文件夹。 + **坚持**如果组件具有多个伴隨文件 (`.ts`、`.html`、`.css`和`.spec`)，就为它创建一个文件夹。 .s-why :marked **Why?** Helps 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. - **为何?**组件通常有四个文件(例如`*.html`、 `*.css`、 `*.ts` 和 `*.spec.ts`)，它们很容易把一个目录弄乱。 + **为何?**组件通常有四个文件 (`*.html`、 `*.css`、 `*.ts` 和 `*.spec.ts`)，它们很容易把一个目录弄乱。 a(id='file-tree') :marked Here is a compliant folder and file structure - 目录和文件结构 + 下面是符合规范的目录和文件结构 .filetree .file <project root> @@ -1652,7 +1746,7 @@ a(id='file-tree') Whatever you choose, be consistent. 把组件放在专用目录中的方式广受欢迎，对于小型应用，还可以保持组件扁平化（而不是放在专用目录中）。 - 这样会把四个文件放在现有目录中，但是也会减少目录的嵌套。无论你如何选择，请保持一致。 + 这样会把四个文件放在现有目录中，也会减少目录的嵌套。无论你如何选择，请保持一致。 a(href="#toc").to-top Back to top @@ -1661,57 +1755,60 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Folders-by-Feature Structure + ### 按特性组织的目录结构 + #### Style 04-07 - #### 风格04-07 + + #### 风格 04-07 .s-rule.do :marked **Do** create folders named for the feature area 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. - **为何？**LIFT原则中包含了所有这些。 + **为何？** LIFT 原则中包含了所有这些。 .s-why :marked **Why?** Helps reduce the app from becoming cluttered through organizing the content and keeping them aligned with the LIFT guidelines. - **为何？**通过精心组织内容并让它们遵循LIFT原则，可以避免应用变得杂乱无章。 + **为何？**遵循 LIFT 原则精心组织内容，避免应用变得杂乱无章。 .s-why :marked **Why?** When there are a lot of files (e.g. 10+), locating them is easier with a consistent folder structure and more difficult in a flat structure. - **为何？**当有很多文件时（比如10个以上），在“专用目录”型结构中定位它们会比在扁平结构中更容易。 + **为何？**当有很多文件时（例如 10 个以上），在专用目录型结构中定位它们会比在扁平结构中更容易。 .s-rule.do :marked **Do** create an Angular module for each feature area. - **坚持**为每个特性区创建一个Angular模块。 + **坚持**为每个特性区创建一个 Angular 模块。 .s-why :marked **Why?** Angular modules make it easy to lazy load routable features. - **为何？**Angular模块能让对可路由的特性进行惰性加载变得更容易。 + **为何？** Angular 模块使延迟加载可路由的特性变得更容易。 .s-why.s-why-last :marked **Why?** Angular modules make it easier to isolate, test, and re-use features. - **为何？**Angular模块能让我们更容易隔离、测试盒复用特性。 + **为何？**Angular 模块隔离、测试和复用特性更容易。 .file-tree-reference a(href="#file-tree") Refer here to this Folder and File Structure example @@ -1726,21 +1823,24 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### App Root Module + ### 应用的根模块 + #### Style 04-08 - #### 风格04-08 + + #### 风格 04-08 .s-rule.do :marked **Do** create an Angular module in the app's root folder (e.g., in `/app`). - **坚持**在应用的根部创建一个Angular模块（比如`/app`）。 + **坚持**在应用的根目录创建一个 Angular 模块（比如`/app`）。 .s-why :marked **Why?** Every app requires at least one root Angular module. - **为何？**每个应用都至少需要一个根Angular模块。 + **为何？**每个应用都至少需要一个根 Angular 模块。 .s-rule.consider :marked @@ -1764,15 +1864,18 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Feature Modules + ### 特性模块 + #### Style 04-09 - #### 风格04-09 + + #### 风格 04-09 .s-rule.do :marked **Do** create an Angular module for all distinct features in an application (e.g. `Heroes` feature). - **坚持**为应用中的每个明显的特性创建一个Angular模块。 + **坚持**为应用中每个明显的特性创建一个 Angular 模块。 .s-rule.do :marked @@ -1784,19 +1887,19 @@ a(href="#toc").to-top 回到顶部 :marked **Do** name the feature module file reflecting the name of the feature area and folder (e.g. `app/heroes/heroes.module.ts`) - **坚持**特性模块的名字应该能反映出特性区的名字和目录（如`app/heroes/heroes.module.ts`）。 + **坚持**特性模块的文件名应该能反映出特性区的名字和目录（如`app/heroes/heroes.module.ts`）。 .s-rule.do :marked **Do** name the feature module symbol reflecting the name of the feature area, folder, and file (e.g. `app/heroes/heroes.module.ts` defines `HeroesModule`) - **坚持**特性模块的符号名应该能反映出特性区、目录和文件的名字（如在`app/heroes/heroes.module.ts`中定义`HeroesModule`）。 + **坚持**特性模块的符号名应该能反映出特性区、目录和文件名（如在`app/heroes/heroes.module.ts`中定义`HeroesModule`）。 .s-why :marked **Why?** A feature module can expose or hide its implementation from other modules. - **为何？** 特性模块可以对其它模块暴露或隐藏自己的实现。 + **为何？**特性模块可以对其它模块暴露或隐藏自己的实现。 .s-why :marked @@ -1808,7 +1911,7 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** A feature module can easily be routed to both eagerly and lazily. - **为何？**特性模块能很容易的被路由器加载 —— 无论使用主动加载还是惰性加载的方式。 + **为何？**方便路由到特性模块 —— 无论是用主动加载还是惰性加载的方式。 .s-why :marked @@ -1820,7 +1923,7 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** A feature module helps clarify and make it easier to assign development responsibilities to different teams. - **为何？**特性模块帮助澄清开发职责，以便于把这些职责指派给不同的开发组。 + **为何？**特性模块帮助澄清开发职责，以便于把这些职责指派给不同的项目组。 .s-why.s-why-last :marked @@ -1835,9 +1938,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Shared Feature Module + ### 共享特性模块 + #### Style 04-10 - #### 风格04-10 + + #### 风格 04-10 .s-rule.do :marked @@ -1849,7 +1955,7 @@ a(href="#toc").to-top 回到顶部 :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). - **坚持**把可能被应用的其它特性模块使用的公共资产（如组件、指令和管道）放在`SharedModule`中，这些资产倾向于共享自己的新实例（而不是单例）。 + **坚持**把可能被应用其它特性模块使用的公共如组件、指令和管道放在`SharedModule`中，这些资产倾向于共享自己的新实例（而不是单例）。 .s-rule.do :marked @@ -1891,15 +1997,15 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** A lazy loaded feature module that imports that shared module will make its own copy of the service and likely have undesireable results. - **为何？**惰性加载的特性模块如果导入了这个共享模块，就会创建一份自己的服务副本，这可能会导致意料之外的后果。 + **为何？**惰性加载的特性模块如果导入了这个共享模块，会创建一份自己的服务副本，这可能会导致意料之外的后果。 .s-why.s-why-last :marked **Why?** You don't want each module to have its own separate instance of singleton services. Yet there is a real danger of that happening if the `SharedModule` provides a service. - **为何？**对于单例服务，你是不会希望每个模块都有自己的一份单独实例的。 - 而如果`SharedModule`提供了一个服务，那就会发生这种情况。 + **为何？**对于单例服务，你不希望每个模块都有自己的实例。 + 而如果`SharedModule`提供了一个服务，那就有可能发生这种情况。 .filetree .file src @@ -1945,15 +2051,18 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Core Feature Module + ### 核心特性模块 + #### Style 04-11 + #### 风格04-11 .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. - **坚持**把那些“只用一次”的类收集到`CoreModule`中，并且对外隐藏它们的实现细节。简化的`AppModule`会导入`CoreModule`，并且把它作为整个应用的总指挥。 + **坚持**把那些“只用一次”的类收集到`CoreModule`中，并对外隐藏它们的实现细节。简化的`AppModule`会导入`CoreModule`，并且把它作为整个应用的总指挥。 .s-rule.do :marked @@ -1999,7 +2108,8 @@ a(href="#toc").to-top 回到顶部 They are not imported elsewhere so they're not shared in that sense. Yet they're too big and messy to leave loose in the root folder. - **为何？**真实世界中的应用会有很多只用一次的组件（比如：加载动画、消息浮层、模态框等），它们只会在`AppComponent`的模板中出现，而不会出现在其它地方，所以它们没有被共享的价值。 + **为何？**真实世界中的应用会有很多只用一次的组件（比如：加载动画、消息浮层、模态框等），它们只会在`AppComponent`的模板中出现。 + 不会在其它地方导入它们，所以没有共享的价值。 然而它们又太大了，放在根目录中就会显得乱七八糟的。 .s-rule.avoid @@ -2024,13 +2134,13 @@ a(href="#toc").to-top 回到顶部 :marked **Do** export all symbols that from the `CoreModule` that the `AppModule` will import and make available for other feature modules to use. - **坚持**从`CoreModule`中导出所有符号，`AppModule`会导入它们，并让它们能在所有特性模块中可用。 + **坚持**从`CoreModule`中导出`AppModule`需导入的所有符号，使它们在所有特性模块中可用。 .s-why :marked **Why?** `CoreModule` exists to make commonly used singleton services available for use in the many other modules. - **为何？**`CoreModule`的存在就能让常用的单例服务在所有其它模块中可用。 + **为何？**`CoreModule`的存在就让常用的单例服务在所有其它模块中可用。 .s-why.s-why-last :marked @@ -2038,9 +2148,9 @@ a(href="#toc").to-top 回到顶部 You don't want each module to have its own separate instance of singleton services. Yet there is a real danger of that happening accidentally if the `CoreModule` provides a service. - **为何？**你会希望整个应用都使用这个单例服务。 - 你不会希望每个模块都有这个单例服务的单独的实例。 - 然而如果`CoreModule`中提供了一个服务，就可能偶尔导致这种后果。 + **为何？**你希望整个应用都使用这个单例服务。 + 你不希望每个模块都有这个单例服务的单独的实例。 + 然而，如果`CoreModule`中提供了一个服务，就可能偶尔导致这种后果。 .filetree .file src @@ -2109,9 +2219,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Prevent Reimport of Core Module + ### 防止多次导入`CoreModule` + #### Style 04-12 - #### 风格04-12 + + #### 风格 04-12 Only the root `AppModule` should import the `CoreModule`. @@ -2154,9 +2267,13 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Lazy Loaded Folders + ### 惰性加载的目录 + #### Style 04-13 - #### 样式04-13 + + #### 样式 04-13 + A distinct application feature or workflow may be *lazy loaded* or *loaded on demand* rather than when the application starts. 某些边界清晰的应用特性或工作流可以做成*惰性加载*或*按需加载*的，而不用总是随着应用启动。 @@ -2182,9 +2299,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Never Directly Import Lazy Loaded Folders + ### 永远不要直接导入惰性加载的目录 + #### Style 04-14 - #### 样式04-14 + + #### 样式 04-14 .s-rule.avoid :marked @@ -2196,7 +2316,7 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** Directly importing and using a module will load it immediately when the intention is to load it on demand. - **为何？**直接导入并使用此模块会主动加载它，而我们原本的设计意图是按需加载它。 + **为何？**直接导入并使用此模块会立即加载它，而原本的设计意图是按需加载它。 a(href="#toc").to-top Back to top @@ -2209,15 +2329,18 @@ a(href="#toc").to-top 回到顶部 ## 组件 ### Component Selector Naming + ### 组件选择器命名 + #### Style 05-02 + #### 风格05-02 .s-rule.do :marked **Do** use _dashed-case_ or _kebab-case_ for naming the element selectors of components. - **坚持**使用*中线（dashed）命名法*或*烤串（kebab）命名法*来命名组件中的元素选择器。 + **坚持**使用*中线 (dashed) 命名法*或*烤串 (kebab) 命名法*来命名组件中的元素选择器。 .s-why.s-why-last :marked @@ -2243,9 +2366,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Components as Elements + ### 把组件当做元素 + #### Style 05-03 - #### 风格05-03 + + #### 风格 05-03 .s-rule.do :marked @@ -2257,21 +2383,21 @@ a(href="#toc").to-top 回到顶部 :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. - **为何？**组件有很多包含HTML以及可选Angular模板语法的模板。它们的功能多数都与把内容放进页面有关，而这和HTML元素的设计意图很相似。 + **为何？**组件有很多包含 HTML 以及可选 Angular 模板语法的模板。它们多数都与把内容放进页面有关，因而组件更接近于元素。 .s-why :marked **Why?** A component represents a visual element on the page. Defining the selector as an HTML element tag is consistent with native HTML elements and WebComponents. - **为何？**组件表示页面上的可视元素。 - 把该选择器定义成HTML元素标签可以与原生HTML和WebComponent保持一致。 + **为何？**组件代表页面上的一个可视元素。 + 把选择器定义成 HTML 元素标签可以与原生 HTML 元素和 WebComponent 保持一致。 .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. - **为何？**查看组件是否有模板HTML文件，是最简单的识别一个符号是组件还是指令的方法。 + **为何？**查看组件模板的 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 @@ -2294,39 +2420,42 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Extract Template and Styles to Their Own Files + ### 把模板和样式提取到它们自己的文件 + #### Style 05-04 - #### 风格05-04 + + #### 风格 05-04 .s-rule.do :marked **Do** extract templates and styles into a separate file, when more than 3 lines. - **坚持**当超过三行的时候，把模板和样式提取到一个单独的文件。 + **坚持**当超过 3 行时，把模板和样式提取到一个单独的文件。 .s-rule.do :marked **Do** name the template file `[component-name].component.html`, where [component-name] is the component name. - **坚持**把模板文件命名为`[component-name].component.html`，这里的[component-name]就是组件名。 + **坚持**把模板文件命名为`[component-name].component.html`，其中，[component-name] 是组件名。 .s-rule.do :marked **Do** name the style file `[component-name].component.css`, where [component-name] is the component name. - **坚持**把样式文件命名为`[component-name].component.css`，这里的[component-name]就是组件名。 + **坚持**把样式文件命名为`[component-name].component.css`，其中，[component-name] 是组件名。 .s-why :marked **Why?** Syntax hints for inline templates in (*.js and *.ts) code files are not supported by some editors. - **为何？**在(*.js和*.ts)代码里面内联模板时，一些编辑器不支持语法提示。 + **为何？**在 (*.js 和 *.ts) 代码里面内联模板时，某些编辑器不支持语法提示。 .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 @@ -2348,35 +2477,38 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Decorate Input and Output Properties Inline - ### 内联Input和Output属性装饰器 + + ### 内联输入和输出属性装饰器 + #### Style 05-12 - #### 风格05-12 + + #### 风格 05-12 .s-rule.do :marked **Do** use `@Input` and `@Output` instead of the `inputs` and `outputs` properties of the `@Directive and `@Component` decorators: - **坚持** 使用`@Directive`和`@Component`装饰器的`@Input`和`@Output`，而非`inputs`和`outputs`属性: + **坚持** 使用`@Input`和`@Output`，而非`@Directive`和`@Component`装饰器的`inputs`和`outputs`属性: .s-rule.do :marked **Do** place the `@Input()` or `@Output()` on the same line as the property they decorate. - **坚持**把`@Input()`或者`@Output()`放到它们装饰的属性的同一行。 + **坚持**把`@Input()`或者`@Output()`放到所装饰的属性的同一行。 .s-why :marked **Why?** It is easier and more readable to identify which properties in a class are inputs or outputs. - **为何？**这样易于在类里面识别哪个属性是inputs或outputs。 + **为何？**易于在类里面识别哪些属性是输入属性或输出属性。 .s-why :marked **Why?** If you ever need to rename the property or event name associated with `@Input` or `@Output`, you can modify it a single place. - **为何？** 如果你需要重命名属性或者`@Input`或者`@Output`关联的事件名字，你可以在一个位置修改。 + **为何？** 如果需要重命名与`@Input`或者`@Output`关联的属性或事件名，你可以在一个位置修改。 .s-why :marked @@ -2403,9 +2535,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Avoid Renaming Inputs and Outputs + ### 避免重命名输入和输出 + #### Style 05-13 - #### 风格05-13 + + #### 风格 05-13 .s-rule.avoid :marked @@ -2417,7 +2552,7 @@ a(href="#toc").to-top 回到顶部 :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. - **为何？**可能导致混乱，造成指令的输入或输出属性的名字与导出的公共API名字不一样。 + **为何？**当指令的输入或输出属性的名字与导出的公共 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 @@ -2440,15 +2575,18 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Member Sequence + ### 成员顺序 + #### Style 05-14 - #### 风格05-14 + + #### 风格 05-14 .s-rule.do :marked **Do** place properties up top followed by methods. - **坚持**把属性成员放到顶部，方法成员紧随其后。 + **坚持**把属性成员放在前面，方法成员放在后面。 .s-rule.do :marked @@ -2461,7 +2599,7 @@ a(href="#toc").to-top 回到顶部 **Why?** Placing members in a consistent sequence makes it easy to read and helps 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 @@ -2476,33 +2614,36 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Put Logic in Services + ### 把逻辑放到服务里 + #### Style 05-15 - #### 风格05-15 + + #### 风格 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. - **为何？**在单元测试时，服务里的逻辑更加容易被隔离。在组件里调用它的逻辑也很容易被模仿Mock。 + **为何？**在单元测试时，服务里的逻辑更容易被隔离。当组件中调用逻辑时，也很容易被模拟。 .s-why :marked @@ -2514,7 +2655,7 @@ a(href="#toc").to-top 回到顶部 :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 @@ -2529,9 +2670,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Don't Prefix Output Properties + ### 不要给输出属性加前缀 + #### Style 05-16 - #### 风格05-16 + + #### 风格 05-16 .s-rule.do :marked @@ -2555,7 +2699,7 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** Angular allows for an [alternative syntax](template-syntax.html#binding-syntax) `on-*`. If the event itself was prefixed with `on` this would result in an `on-onEvent` binding expression. - **为何？**Angular允许[另一种备选语法](template-syntax.html#binding-syntax) `on-*`。如果事件的名字本身带有前缀`on`，那么绑定的表达式可能是`on-onEvent`。 + **为何？**Angular 允许[另一种备选语法](template-syntax.html#binding-syntax) `on-*`。如果事件的名字本身带有前缀`on`，那么绑定的表达式可能是`on-onEvent`。 +makeExample('style-guide/ts/05-16/app/heroes/hero.component.avoid.ts', 'example', 'app/heroes/hero.component.ts')(avoid=1) :marked @@ -2578,9 +2722,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Put Presentation Logic in the Component Class - ### 把展示逻辑放到组件类里 + + ### 把表现层逻辑放到组件类里 + #### Style 05-17 - #### 风格05-17 + + #### 风格 05-17 .s-rule.do :marked @@ -2598,7 +2745,7 @@ a(href="#toc").to-top 回到顶部 :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 @@ -2620,27 +2767,30 @@ a(href="#toc").to-top Back to top .l-main-section :marked ### Use Directives to Enhance an Existing Element + ### 使用指令来加强已有元素 + #### Style 06-01 - #### 风格06-01 + + #### 风格 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 @@ -2655,9 +2805,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Use HostListener and HostBinding Class Decorators - ### 使用HostListener和HostBinding类装饰器 + + ### 使用 HostListener 和 HostBinding 类装饰器 + #### Style 06-03 - #### 风格06-03 + + #### 风格 06-03 .s-rule.consider :marked @@ -2679,7 +2832,7 @@ a(href="#toc").to-top 回到顶部 If you use the `host` metadata property, you must modify both the property declaration inside the controller, and the metadata associated with the directive. - **为何？**对于关联到`@HostBinding`的属性或关联到`@HostListener`的方法，要改名时只要在指令类中修改一次就行了。 + **为何？**对于关联到`@HostBinding`的属性或关联到`@HostListener`的方法，要修改时，只需在指令类中的一个地方修改。 如果使用元数据属性`host`，你就得在组件类中修改属性声明的同时修改相关的元数据。 +makeExample('style-guide/ts/06-03/app/shared/validator.directive.ts', '', 'app/shared/validator.directive.ts') @@ -2692,7 +2845,7 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** The `host` metadata is only one term to remember and doesn't require extra ES imports. - **为何？**`host`元数据只是一个便于记忆的名字而已，并不需要额外的ES导入。 + **为何？**`host`元数据只是一个便于记忆的名字而已，并不需要额外的 ES 导入。 +makeExample('style-guide/ts/06-03/app/shared/validator2.directive.ts', '', 'app/shared/validator2.directive.ts') :marked @@ -2704,30 +2857,34 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ## Services + ## 服务 ### Services are Singletons within an Injector - ### 在同一个注入器中，服务总是单例的 + + ### 注入器中，服务总是单例的 + #### Style 07-01 - #### 风格07-01 + + #### 风格 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 @@ -2739,21 +2896,24 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Single Responsibility + ### 单一职责 + #### Style 07-02 - #### 风格07-02 + + #### 风格 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 @@ -2774,38 +2934,41 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Providing a Service + ### 提供一个服务 + #### Style 07-03 - #### 风格07-03 + + #### 风格 07-03 .s-rule.do :marked **Do** provide services to the Angular injector at the top-most component where they will be shared. - **坚持**在被共享范围内的顶级组件里，将服务提供到Angular 2的注入器里。 + **坚持**将服务提供到共享范围内的顶级组件的 Angular 注入器。 .s-why :marked **Why?** The Angular injector is hierarchical. - **为何？**Angular注入器是层次性的。 + **为何？** Angular 注入器是层次化的。 .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, @@ -2822,9 +2985,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Use the @Injectable() Class Decorator - ### 使用@Injectable()类装饰器 + + ### 使用 @Injectable() 类装饰器 + #### Style 07-04 - #### 风格07-04 + + #### 风格 07-04 .s-rule.do :marked @@ -2836,7 +3002,7 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** The Angular DI mechanism resolves all dependencies of services based on their types declared with the services' constructors. - **为何？**Angular的DI机制会基于在服务的构造函数中所声明的类型来解析这些服务的依赖。 + **为何？** Angular 的 DI 机制会根据服务的构造函数参数的声明类型来解析服务的所有依赖。 .s-why.s-why-last :marked @@ -2857,42 +3023,46 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ## Data Services + ## 数据服务 ### Separate Data Calls + ### 分离数据调用 + #### Style 08-01 - #### 风格08-01 + + #### 风格 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. - **坚持**让数据服务来负责XHR调用、本地储存、内存储存或者其它数据操作。 + **坚持**让数据服务来负责 XHR 调用、本地储存、内存储存或者其它数据操作。 .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. - **为何？**数据服务的实现可能有非常具体的代码来处理数据仓库，包括数据头(headers)、如何与数据交谈或者其它服务(比如`Http`)。把逻辑分离到数据服务可以把该逻辑封装到一个地方，对外部使用者(比如组件)隐藏具体的实施细节。 + **为何？**数据服务的实现可能有非常具体的代码来处理数据仓库，包括数据头 (headers)、如何与数据交谈或者其它服务 (比如`Http`)。把逻辑分离到数据服务可以将该逻辑封装在一个地方，对外部使用者（如组件）隐藏具体的实施细节。 a(href="#toc").to-top Back to top @@ -2901,11 +3071,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ## Lifecycle Hooks + ## 生命周期钩子 Use Lifecycle Hooks to tap into important events exposed by Angular. - 使用生命周期钩子来介入到Angular暴露的重要事件里。 + 使用生命周期钩子来介入到 Angular 暴露的重要事件里。 a(href="#toc").to-top Back to top @@ -2914,9 +3085,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Implement Lifecycle Hooks Interfaces + ### 实现生命周期钩子接口 + #### Style 09-01 - #### 风格09-01 + + #### 风格 09-01 .s-rule.do :marked @@ -2929,7 +3103,7 @@ a(href="#toc").to-top 回到顶部 **Why?** Strongly-typed method signatures. The compiler and editor can call out misspellings. - **为何？**如果使用强类型的方法签名，那么编译器和编辑器可以帮你揪出拼写错误。 + **为何？**如果使用强类型的方法签名，编译器和编辑器可以帮你揪出拼写错误。 +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 @@ -2944,11 +3118,12 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ## Appendix + ## 附录 Useful tools and tips for Angular. - 有用的Angular工具和小提示 + 有用的 Angular 工具和小提示 a(href="#toc").to-top Back to top @@ -2957,21 +3132,24 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### Codelyzer + ### Codelyzer + #### Style A-01 - #### 风格A-01 + + #### 风格 A-01 .s-rule.do :marked **Do** use [codelyzer](https://www.npmjs.com/package/codelyzer) to follow this guide. - **坚持**使用[codelyzer](https://www.npmjs.com/package/codelyzer)来实施本指南。 + **坚持**使用 [codelyzer](https://www.npmjs.com/package/codelyzer) 来实施本指南。 .s-rule.consider :marked **Consider** adjusting the rules in codelyzer to suit your needs. - **考虑**调整codelyzer的规则来满足你的需求。 + **考虑**调整 codelyzer 的规则来满足你的需求。 a(href="#toc").to-top Back to top @@ -2980,33 +3158,24 @@ a(href="#toc").to-top 回到顶部 .l-main-section :marked ### File Templates and Snippets + ### 文档模板和代码片段 + #### Style A-02 - #### 风格A-02 + + #### 风格 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. - **坚持**使用文件模板或代码片段来帮助实现一致的风格和模式。下面是为一些网络开发编辑器和IDE准备的模板和/或代码片段： + **坚持**使用文件模板或代码片段来帮助实现一致的风格和模式。下面是为一些网络开发编辑器和 IDE 准备的模板和/或代码片段： .s-rule.consider :marked - **Consider** using [snippets](https://atom.io/packages/angular-2-typescript-snippets) for [Atom](https://atom.io/) that follow these styles and guidelines. - - **考虑** 使用[Atom](https://atom.io/)的[代码片段](https://atom.io/packages/angular-2-typescript-snippets)来实施本风格指南。 - - **Consider** using [snippets](https://github.com/orizens/sublime-angular2-snippets) for [Sublime Text](http://www.sublimetext.com/) that follow these styles and guidelines. - - **考虑** 使用[Sublime Text](http://www.sublimetext.com/)的[代码片段](https://github.com/orizens/sublime-angular2-snippets)来实施本风格指南。 - - **Consider** using [snippets](https://github.com/mhartington/vim-angular2-snippets) for [Vim](http://www.vim.org/) that follow these styles and guidelines. - - **考虑** 使用[Vim](http://www.vim.org/)的[代码片段](https://github.com/mhartington/vim-angular2-snippets)来实施本风格指南。 - **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. - **考虑**使用[Visual Studio Code](https://code.visualstudio.com/)的[代码片段](https://marketplace.visualstudio.com/items?itemName=johnpapa.Angular2)来实施本风格指南。 + **考虑**使用 [Visual Studio Code](https://code.visualstudio.com/)的[代码片段](https://marketplace.visualstudio.com/items?itemName=johnpapa.Angular2) 来实施本风格指南。 Use Extension @@ -3015,15 +3184,15 @@ a(href="#toc").to-top 回到顶部 :marked **Consider** using [snippets](https://atom.io/packages/angular-2-typescript-snippets) for [Atom](https://atom.io/) that follow these styles and guidelines. - **考虑**使用[Atom](https://atom.io/)的[代码片断](https://atom.io/packages/angular-2-typescript-snippets)来实施本风格指南。 + **考虑**使用 [Atom](https://atom.io/) 的[代码片断](https://atom.io/packages/angular-2-typescript-snippets)来实施本风格指南。 **Consider** using [snippets](https://github.com/orizens/sublime-angular2-snippets) for [Sublime Text](http://www.sublimetext.com/) that follow these styles and guidelines. - **考虑**使用[Sublime Text](http://www.sublimetext.com/)的[代码片断](https://github.com/orizens/sublime-angular2-snippets)来实施本风格指南。 + **考虑**使用 [Sublime Text](http://www.sublimetext.com/)的[代码片断](https://github.com/orizens/sublime-angular2-snippets) 来实施本风格指南。 **Consider** using [snippets](https://github.com/mhartington/vim-angular2-snippets) for [Vim](http://www.vim.org/) that follow these styles and guidelines. - **考虑**使用[Vim](http://www.vim.org/)的[代码片断](https://github.com/mhartington/vim-angular2-snippets)来实施本风格指南。 + **考虑**使用 [Vim](http://www.vim.org/) 的[代码片断](https://github.com/mhartington/vim-angular2-snippets)来实施本风格指南。 a(href="#toc").to-top Back to top diff --git a/public/translate/cn/translate.js b/public/translate/cn/translate.js index 882ddf12df..56c08023c2 100644 --- a/public/translate/cn/translate.js +++ b/public/translate/cn/translate.js @@ -31,7 +31,7 @@ var sourceVisible = localStorage.getItem('source-visible') === 'true'; var count = 0; for (var i = 0; i < container.children.length; i++) { var node = container.children[i]; - var ignoredTagNames = ['CODE-EXAMPLE', 'SCRIPT', 'CODE', 'EM']; + var ignoredTagNames = ['CODE-EXAMPLE', 'SCRIPT', 'CODE', 'EM', 'STRONG']; // ignore example code. if (node.classList.contains('code-example') || ignoredTagNames.indexOf(node.tagName) >= 0) { From 3b13471cb4bf4c4e3fe4f240280024c5fe1eca45 Mon Sep 17 00:00:00 2001 From: Yang Lin Date: Tue, 29 Nov 2016 21:52:54 +0800 Subject: [PATCH 2/3] Polish style-guild.jade 2 --- public/docs/ts/latest/guide/style-guide.jade | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/public/docs/ts/latest/guide/style-guide.jade b/public/docs/ts/latest/guide/style-guide.jade index d08d8aeedd..a20129f2aa 100644 --- a/public/docs/ts/latest/guide/style-guide.jade +++ b/public/docs/ts/latest/guide/style-guide.jade @@ -144,7 +144,7 @@ a(id='toc') :marked **Do** define one thing (e.g. service or component) per file. - **坚持**每个文件只定义一样东西（如服务或组件）。 + **坚持**每个文件只定义一样东西（例如服务或组件）。 .s-rule.consider :marked @@ -215,7 +215,7 @@ a(href="#toc").to-top 回到顶部 :marked ### Small Functions - ### 小函数 + ### 简单函数 #### Style 01-02 @@ -225,7 +225,7 @@ a(href="#toc").to-top 回到顶部 :marked **Do** define small functions - **坚持**定义小函数 + **坚持**定义简单函数 .s-rule.consider :marked @@ -236,31 +236,31 @@ a(href="#toc").to-top 回到顶部 :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").to-top Back to top @@ -375,7 +375,7 @@ a(href="#toc").to-top 回到顶部 **Why?** Unabbreviated type names such as `.service` are descriptive and unambiguous. Abbreviations such as `.srv`, `.svc`, and `.serv` can be confusing. - **为何？** 象`.service`这样的没有简写过的类型名字，描述清楚，毫不含糊。 + **为何？** 像`.service`这样的没有简写过的类型名字，描述清楚，毫不含糊。 像`.srv`, `.svc`, 和 `.serv`这样的简写可能令人困惑。 .s-why.s-why-last @@ -554,7 +554,7 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** Clear service names such as `Logger` do not require a suffix. - **为何？**象`Logger`这样的清楚的服务名不需要后缀。 + **为何？**像`Logger`这样的清楚的服务名不需要后缀。 .s-why.s-why-last :marked From 39512ebcda9c33f7b71753ad8ba798c5b426db85 Mon Sep 17 00:00:00 2001 From: Yang Lin Date: Tue, 29 Nov 2016 23:36:27 +0800 Subject: [PATCH 3/3] =?UTF-8?q?=E4=BD=BF=E7=94=A8=E2=80=9C=E4=BE=8B?= =?UTF-8?q?=E5=A6=82=E2=80=9D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- public/docs/ts/latest/guide/style-guide.jade | 46 ++++++++++---------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/public/docs/ts/latest/guide/style-guide.jade b/public/docs/ts/latest/guide/style-guide.jade index a20129f2aa..04d1f088a1 100644 --- a/public/docs/ts/latest/guide/style-guide.jade +++ b/public/docs/ts/latest/guide/style-guide.jade @@ -260,7 +260,7 @@ a(href="#toc").to-top 回到顶部 :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").to-top Back to top @@ -415,14 +415,14 @@ a(href="#toc").to-top 回到顶部 **Do** append the symbol name with the conventional suffix for a thing of that type (e.g., `Component`, `Directive`, `Module`, `Pipe`, `Service`). - **坚持**在符号名后面追加约定的类型后缀（如`Component`、`Directive`、`Module`、`Pipe`、`Service`）。 + **坚持**在符号名后面追加约定的类型后缀（例如`Component`、`Directive`、`Module`、`Pipe`、`Service`）。 .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`). - **坚持**在文件名后面追加约定的类型后缀（如`.component.ts`、`.directive.ts`、`.module.ts`、`.pipe.ts`、`.service.ts`）。 + **坚持**在文件名后面追加约定的类型后缀（例如`.component.ts`、`.directive.ts`、`.module.ts`、`.pipe.ts`、`.service.ts`）。 .s-why :marked **Why?** Provides a consistent way to quickly identify and reference assets. @@ -542,7 +542,7 @@ a(href="#toc").to-top 回到顶部 :marked **Do** suffix services with `Service` when it is not clear what they are (e.g. when they are nouns). - **坚持**添加`Service`后缀，当不清楚它们是什么时（例如，当它们是名词时）。 + **坚持**添加`Service`后缀，当不清楚它们是什么时（例如当它们是名词时）。 .s-why :marked @@ -696,7 +696,7 @@ a(href="#toc").to-top 回到顶部 :marked **Do** use a hyphenated, lowercase element selector value (e.g. `admin-users`). - **坚持**使用带连字符的小写元素选择器值（比如`admin-users`）。 + **坚持**使用带连字符的小写元素选择器值（例如`admin-users`）。 .s-rule.do :marked @@ -755,7 +755,7 @@ a(href="#toc").to-top 回到顶部 :marked **Do** use a custom prefix for the selector of directives (e.g, the prefix `toh` from **T**our **o**f **H**eroes). - **坚持**为指令的选择器添加自定义前缀（比如前缀`toh`来自**T**our **o**f **H**eroes）。 + **坚持**为指令的选择器添加自定义前缀（例如前缀`toh`来自**T**our **o**f **H**eroes）。 .s-rule.do :marked @@ -1566,7 +1566,7 @@ a(href="#toc").to-top 回到顶部 :marked **Consider** configuring the IDE to hide distracting, irrelevant files such as generated `.js` and `.js.map` files. - **考虑**配置 IDE，以隐藏无关的文件，比如生成出来的`.js`文件和`.js.map`文件等。 + **考虑**配置 IDE，以隐藏无关的文件，例如生成出来的`.js`文件和`.js.map`文件等。 s-why.s-why-last :marked @@ -1625,7 +1625,7 @@ a(href="#toc").to-top 回到顶部 **为何？**虽然 DRY 很重要，但如果要以牺牲 LIFT 的其它原则为代价，那就不值得了。 这也就是为什么它被称为 *T-DRY*。 - 比如，把组件命名为`hero-view.component.html`是多余的，因为组件显然就是一个视图 (view)。 + 例如，把组件命名为`hero-view.component.html`是多余的，因为组件显然就是一个视图 (view)。 但如果它不那么显著，或不符合常规，就把它写出来。 a(href="#toc").to-top Back to top @@ -1834,7 +1834,7 @@ a(href="#toc").to-top 回到顶部 :marked **Do** create an Angular module in the app's root folder (e.g., in `/app`). - **坚持**在应用的根目录创建一个 Angular 模块（比如`/app`）。 + **坚持**在应用的根目录创建一个 Angular 模块（例如`/app`）。 .s-why :marked @@ -1881,19 +1881,19 @@ a(href="#toc").to-top 回到顶部 :marked **Do** place the feature module in the same named folder as the feature area (.e.g `app/heroes`). - **坚持**把特性模块放在与特性区同名的目录中（如`app/heroes`）。 + **坚持**把特性模块放在与特性区同名的目录中（例如`app/heroes`）。 .s-rule.do :marked **Do** name the feature module file reflecting the name of the feature area and folder (e.g. `app/heroes/heroes.module.ts`) - **坚持**特性模块的文件名应该能反映出特性区的名字和目录（如`app/heroes/heroes.module.ts`）。 + **坚持**特性模块的文件名应该能反映出特性区的名字和目录（例如`app/heroes/heroes.module.ts`）。 .s-rule.do :marked **Do** name the feature module symbol reflecting the name of the feature area, folder, and file (e.g. `app/heroes/heroes.module.ts` defines `HeroesModule`) - **坚持**特性模块的符号名应该能反映出特性区、目录和文件名（如在`app/heroes/heroes.module.ts`中定义`HeroesModule`）。 + **坚持**特性模块的符号名应该能反映出特性区、目录和文件名（例如在`app/heroes/heroes.module.ts`中定义`HeroesModule`）。 .s-why :marked @@ -1949,25 +1949,25 @@ a(href="#toc").to-top 回到顶部 :marked **Do** create a feature module named `SharedModule` in a `shared` folder (e.g. `app/shared/shared.module.ts` defines `SharedModule`). - **坚持**在`shared`目录中创建名叫`SharedModule`的特性模块（比如在`app/shared/shared.module.ts`中定义`SharedModule`）。 + **坚持**在`shared`目录中创建名叫`SharedModule`的特性模块（例如在`app/shared/shared.module.ts`中定义`SharedModule`）。 .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). - **坚持**把可能被应用其它特性模块使用的公共如组件、指令和管道放在`SharedModule`中，这些资产倾向于共享自己的新实例（而不是单例）。 + **坚持**把可能被应用其它特性模块使用的公共组件、指令和管道放在`SharedModule`中，这些资产倾向于共享自己的新实例（而不是单例）。 .s-rule.do :marked **Do** import all modules required by the assets in the `SharedModule` (e.g. `CommonModule` and `FormsModule`). - **坚持**在`SharedModule`中导入所有模块都需要的资产（比如：`CommonModule`和`FormsModule`）。 + **坚持**在`SharedModule`中导入所有模块都需要的资产（例如`CommonModule`和`FormsModule`）。 .s-why :marked **Why?** `SharedModule` will contain components, directives and pipes that may need features from another common module (e.g. `ngFor` in `CommonModule`). - **为何？** `SharedModule`中包含的组件、指令和管道可能需要来自其它公共模块的特性（比如来自`CommonModule`中的`ngFor`指令）。 + **为何？** `SharedModule`中包含的组件、指令和管道可能需要来自其它公共模块的特性（例如来自`CommonModule`中的`ngFor`指令）。 .s-rule.do :marked @@ -2068,19 +2068,19 @@ a(href="#toc").to-top 回到顶部 :marked **Do** create a feature module named `CoreModule` in a `core` folder (e.g. `app/core/core.module.ts` defines `CoreModule`). - **坚持**在`core`目录下创建一个名叫`CoreModule`的特性模块（比如在`app/core/core.module.ts`中定义`CoreModule`）。 + **坚持**在`core`目录下创建一个名叫`CoreModule`的特性模块（例如在`app/core/core.module.ts`中定义`CoreModule`）。 .s-rule.do :marked **Do** put a singleton service whose instance wil be shared throughout the application in the `CoreModule` (e.g. `ExceptionService` and `LoggerService`). - **坚持**把一个要共享给整个应用的单例服务放进`CoreModule`中（比如`ExceptionService`和`LoggerService`）。 + **坚持**把一个要共享给整个应用的单例服务放进`CoreModule`中（例如`ExceptionService`和`LoggerService`）。 .s-rule.do :marked **Do** import all modules required by the assets in the `CoreModule` (e.g. `CommonModule` and `FormsModule`). - **坚持**导入`CoreModule`中的资产所需要的全部模块（比如`CommonModule`和`FormsModule`）。 + **坚持**导入`CoreModule`中的资产所需要的全部模块（例如`CommonModule`和`FormsModule`）。 .s-why :marked @@ -2100,7 +2100,7 @@ a(href="#toc").to-top 回到顶部 Import it once (in the `AppModule`) when the app starts and never import it anywhere else. (e.g. `NavComponent` and `SpinnerComponent`). **坚持**把应用级、只用一次的组件收集到`CoreModule`中。 - 只在应用启动时从`AppModule`中导入它一次，以后再也不要导入它（比如`NavComponent`和`SpinnerComponent`）。 + 只在应用启动时从`AppModule`中导入它一次，以后再也不要导入它（例如`NavComponent`和`SpinnerComponent`）。 .s-why :marked @@ -2108,7 +2108,7 @@ a(href="#toc").to-top 回到顶部 They are not imported elsewhere so they're not shared in that sense. Yet they're too big and messy to leave loose in the root folder. - **为何？**真实世界中的应用会有很多只用一次的组件（比如：加载动画、消息浮层、模态框等），它们只会在`AppComponent`的模板中出现。 + **为何？**真实世界中的应用会有很多只用一次的组件（例如加载动画、消息浮层、模态框等），它们只会在`AppComponent`的模板中出现。 不会在其它地方导入它们，所以没有共享的价值。 然而它们又太大了，放在根目录中就会显得乱七八糟的。 @@ -2693,7 +2693,7 @@ a(href="#toc").to-top 回到顶部 :marked **Why?** This is consistent with built-in events such as button clicks. - **为何？**与内置事件命名一致，比如按钮点击。 + **为何？**与内置事件命名一致，例如按钮点击。 .s-why.s-why-last :marked @@ -3062,7 +3062,7 @@ a(href="#toc").to-top 回到顶部 :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. - **为何？**数据服务的实现可能有非常具体的代码来处理数据仓库，包括数据头 (headers)、如何与数据交谈或者其它服务 (比如`Http`)。把逻辑分离到数据服务可以将该逻辑封装在一个地方，对外部使用者（如组件）隐藏具体的实施细节。 + **为何？**数据服务的实现可能有非常具体的代码来处理数据仓库，包括数据头 (headers)、如何与数据交谈或者其它服务 (例如`Http`)。把逻辑分离到数据服务可以将该逻辑封装在一个地方，对外部使用者（例如组件）隐藏具体的实施细节。 a(href="#toc").to-top Back to top