lazy-loading统一翻译为惰性加载
This commit is contained in:
Zhicheng Wang
parent
557029074f
commit
72b0ec623e
|
|
@ -761,7 +761,7 @@ a(id='usevalue')
|
|||
:marked
|
||||
The other providers create their values *lazily* when they're needed for injection.
|
||||
|
||||
其它提供商只在需要注入它们的时候才创建并*延迟加载*它们的值。
|
||||
其它提供商只在需要注入它们的时候才创建并*惰性加载*它们的值。
|
||||
|
||||
.l-main-section
|
||||
a(id='useclass')
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ block includes
|
|||
The [Angular Modules chapter](../guide/ngmodule.html) covers the concepts and takes you step by step
|
||||
from the most elementary `@NgModule` to a multi-faceted sample with lazy loaded modules.
|
||||
|
||||
[Angular模块](../guide/ngmodule.html)章涵盖了此概念，并带你一步步的从最基本的`@NgModule`到包罗万象的延迟加载模块。
|
||||
[Angular模块](../guide/ngmodule.html)章涵盖了此概念，并带你一步步的从最基本的`@NgModule`到包罗万象的惰性加载模块。
|
||||
|
||||
_This_ chapter answers the questions many developers ask about Angular Module design and implementation.
|
||||
|
||||
|
|
@ -72,7 +72,7 @@ block includes
|
|||
* [Why is a service provided in a feature module visible everywhere?](#q-module-provider-visibility)
|
||||
* [为什么特性模块中提供的服务是到处可见的？](#q-module-provider-visibility)
|
||||
* [Why is a service provided in a _lazy loaded_ module visible only to that module?](#q-lazy-loaded-module-provider-visibility)
|
||||
* [为什么*延迟加载*模块中的服务提供商只对那个模块本身可见？](#q-lazy-loaded-module-provider-visibility)
|
||||
* [为什么*惰性加载*模块中的服务提供商只对那个模块本身可见？](#q-lazy-loaded-module-provider-visibility)
|
||||
* [What if two modules provide the _same_ service?](#q-module-provider-duplicates)
|
||||
* [如果两个模块提供了*同一个*服务会怎样？](#q-module-provider-duplicates)
|
||||
* [How do I restrict service scope to a module?](#q-component-scoped-providers)
|
||||
|
|
@ -82,9 +82,9 @@ block includes
|
|||
* [Should I add other providers to a module or a component?](#q-component-or-module)
|
||||
* [我应该把其它提供商添加到模块中还是组件中？](#q-component-or-module)
|
||||
* [Why is it bad if _SharedModule_ provides a service to a lazy loaded module?](#q-why-bad)
|
||||
* [为什么让*SharedModule*为延迟加载模块提供服务是个馊主意？](#q-why-bad)
|
||||
* [为什么让*SharedModule*为惰性加载模块提供服务是个馊主意？](#q-why-bad)
|
||||
* [Why does lazy loading create a child injector?](#q-why-child-injector)
|
||||
* [为什么延迟加载模块要创建一个子注入器？](#q-why-child-injector)
|
||||
* [为什么惰性加载模块要创建一个子注入器？](#q-why-child-injector)
|
||||
* [How can I tell if a module or service was previously loaded?](#q-is-it-loaded)
|
||||
* [我要怎样才能知道一个模块或服务已经被加载过？](#q-is-it-loaded)
|
||||
|
||||
|
|
@ -309,14 +309,14 @@ a#q-browser-vs-common-module
|
|||
They need the common directives. They don't need to re-install the app-wide providers.
|
||||
|
||||
在其它任何模块中都*不要导入*`BrowserModule`。
|
||||
*特性模块*和*延迟加载模块*应该改成导入`CommonModule`。
|
||||
*特性模块*和*惰性加载模块*应该改成导入`CommonModule`。
|
||||
它们需要通用的指令。它们不需要重新初始化全应用级的提供商。
|
||||
|
||||
.l-sub-section
|
||||
:marked
|
||||
`BrowserModule` throws an error if you try to lazy load a module that imports it.
|
||||
|
||||
如果你在延迟加载模块中导入`BrowserModule`，Angular就会抛出一个错误。
|
||||
如果你在惰性加载模块中导入`BrowserModule`，Angular就会抛出一个错误。
|
||||
|
||||
:marked
|
||||
Importing `CommonModule` also frees feature modules for use on _any_ target platform, not just browsers,
|
||||
|
|
@ -489,12 +489,12 @@ a#q-for-root
|
|||
is contrary to the intent and is likely to produce a runtime error.
|
||||
|
||||
只能在应用的根模块`AppModule`中调用并导入`.forRoot`的结果。
|
||||
在其它模块中导入它，特别是延迟加载模块中，是违反设计目标的并会导致一个运行时错误。
|
||||
在其它模块中导入它，特别是惰性加载模块中，是违反设计目标的并会导致一个运行时错误。
|
||||
|
||||
:marked
|
||||
`RouterModule` also offers a `forChild` static method for configuring the routes of lazy loaded modules.
|
||||
|
||||
`RouterModule`也提供了静态方法`forChild`，用于配置延迟加载模块的路由。
|
||||
`RouterModule`也提供了静态方法`forChild`，用于配置惰性加载模块的路由。
|
||||
|
||||
**_forRoot_** and **_forChild_** are conventional names for methods that
|
||||
configure services in root and feature modules respectively.
|
||||
|
|
@ -559,29 +559,29 @@ a#q-lazy-loaded-module-provider-visibility
|
|||
:marked
|
||||
### Why is a service provided in a lazy loaded module visible only to that module?
|
||||
|
||||
### 为什么在延迟加载模块中声明的服务提供商只对该模块自身可见？
|
||||
### 为什么在惰性加载模块中声明的服务提供商只对该模块自身可见？
|
||||
|
||||
Unlike providers of the modules loaded at launch,
|
||||
providers of lazy loaded modules are *module-scoped*.
|
||||
|
||||
和启动时就加载的模块中的提供商不同，延迟加载模块中的提供商是*局限于模块*的。
|
||||
和启动时就加载的模块中的提供商不同，惰性加载模块中的提供商是*局限于模块*的。
|
||||
|
||||
When the Angular router lazy-loads a module, it creates a new execution context.
|
||||
That [context has its own injector](#q-why-child-injector "Why Angular creates a child injector") which is a direct child of the application injector.
|
||||
|
||||
当Angular路由器延迟加载一个模块时，它创建了一个新的运行环境。
|
||||
当Angular路由器惰性加载一个模块时，它创建了一个新的运行环境。
|
||||
那个环境[拥有自己的注入器](#q-why-child-injector "为什么Angular会创建子注入器")，它是应用注入器的直属子级。
|
||||
|
||||
The router adds the lazy module's providers and the providers of its imported modules to this child injector.
|
||||
|
||||
路由器把该延迟加载模块的提供商和它导入的模块的提供商添加到这个子注入器中。
|
||||
路由器把该惰性加载模块的提供商和它导入的模块的提供商添加到这个子注入器中。
|
||||
|
||||
These providers are insulated from changes to application providers with the same lookup token.
|
||||
When the router creates a component within the lazy loaded context,
|
||||
Angular prefers service instances created from these providers to the service instances of the application root injector.
|
||||
|
||||
这些提供商不会被拥有相同令牌的应用级别提供商的变化所影响。
|
||||
当路由器在延迟加载环境中创建组件时，Angular优先使用延迟加载模块中的服务实例，而不是来自应用的根注入器的。
|
||||
当路由器在惰性加载环境中创建组件时，Angular优先使用惰性加载模块中的服务实例，而不是来自应用的根注入器的。
|
||||
|
||||
.l-hr
|
||||
a#q-module-provider-duplicates
|
||||
|
|
@ -674,8 +674,8 @@ a#q-component-scoped-providers
|
|||
Angular gives a [lazy-loaded module](#q-lazy-loaded-module-provider-visibility) its own child injector.
|
||||
The module's providers are visible only within the component tree created with this injector.
|
||||
|
||||
只要可能，就让模块延迟加载。
|
||||
Angular给了[延迟加载模块](#q-lazy-loaded-module-provider-visibility)自己的子注入器。
|
||||
只要可能，就让模块惰性加载。
|
||||
Angular给了[惰性加载模块](#q-lazy-loaded-module-provider-visibility)自己的子注入器。
|
||||
该模块中的提供商只对由该注入器创建的组件树可见。
|
||||
|
||||
If you must load the module eagerly, when the application starts,
|
||||
|
|
@ -734,7 +734,7 @@ a#q-root-component-or-module
|
|||
Lazy-loaded modules and their components can inject `AppModule` services;
|
||||
they cannot inject `AppComponent` services.
|
||||
|
||||
延迟加载模块及其组件可以注入`AppModule`中的服务，却不能注入`AppComponent`中的。
|
||||
惰性加载模块及其组件可以注入`AppModule`中的服务，却不能注入`AppComponent`中的。
|
||||
|
||||
Register a service in `AppComponent` providers _only_ if the service must be hidden
|
||||
from components outside the `AppComponent` tree. This is a rare exceptional use case.
|
||||
|
|
@ -785,7 +785,7 @@ a#q-root-component-or-module
|
|||
The application would fail the moment a user navigated to "Heroes".
|
||||
|
||||
当有路由时，`AppComponent`服务并不在根部。
|
||||
延迟加载的模块就不能用它们。
|
||||
惰性加载的模块就不能用它们。
|
||||
在“Angular模块”章的范例应用中，如果我们在`AppComponent`中注册`UserService`，那么`HeroComponent`就不能注入它。
|
||||
一旦用户导航到“Heroes”特性区，该应用就会失败。
|
||||
|
||||
|
|
@ -830,7 +830,7 @@ a#q-why-bad
|
|||
:marked
|
||||
### Why is it bad if _SharedModule_ provides a service to a lazy loaded module?
|
||||
|
||||
### 为什么*SharedModule*为延迟加载模块提供服务是个馊主意？
|
||||
### 为什么*SharedModule*为惰性加载模块提供服务是个馊主意？
|
||||
|
||||
This question arose in the [Angular Module](../guide/ngmodule.html#no-shared-module-providers) chapter
|
||||
when we discussed the importance of keeping providers out of the `SharedModule`.
|
||||
|
|
@ -858,12 +858,12 @@ a#q-why-bad
|
|||
|
||||
Now consider the `HeroModule` _which is lazy loaded!_
|
||||
|
||||
现在，该考虑`HeroModule`了，*它是延迟加载的！*。
|
||||
现在，该考虑`HeroModule`了，*它是惰性加载的！*。
|
||||
|
||||
When the router lazy loads the `HeroModule`, it creates a child injector and registers the `UserService`
|
||||
provider with that child injector. The child injector is _not_ the root injector.
|
||||
|
||||
当路由器准备延迟加载`HeroModule`的时候，它会创建一个子注入器，并且把`UserService`的提供商注册到那个子注入器中。子注入器和根注入器是*不同*的。
|
||||
当路由器准备惰性加载`HeroModule`的时候，它会创建一个子注入器，并且把`UserService`的提供商注册到那个子注入器中。子注入器和根注入器是*不同*的。
|
||||
|
||||
When Angular creates a lazy `HeroComponent`, it must inject a `UserService`.
|
||||
This time it finds a `UserService` provider in the lazy module's _child injector_
|
||||
|
|
@ -871,8 +871,8 @@ a#q-why-bad
|
|||
This is an entirely different `UserService` instance
|
||||
than the app-wide singleton version that Angular injected in one of the eagerly loaded components.
|
||||
|
||||
当Angular创建一个延迟加载的`HeroComponent`时，它必须注入一个`UserService`。
|
||||
这次，它会从延迟加载模块的*子注入器*中查找`UserService`的提供商，并用它创建一个`UserService`的新实例。
|
||||
当Angular创建一个惰性加载的`HeroComponent`时，它必须注入一个`UserService`。
|
||||
这次，它会从惰性加载模块的*子注入器*中查找`UserService`的提供商，并用它创建一个`UserService`的新实例。
|
||||
这个`UserService`实例与Angular在立即加载的组件中注入的那个全应用级单例对象截然不同。
|
||||
|
||||
That's almost certainly a mistake.
|
||||
|
|
@ -899,23 +899,23 @@ a#q-why-child-injector
|
|||
:marked
|
||||
### Why does lazy loading create a child injector?
|
||||
|
||||
### 为什么延迟加载模块会创建一个子注入器？
|
||||
### 为什么惰性加载模块会创建一个子注入器？
|
||||
|
||||
Angular adds `@NgModule.providers` to the application root injector ... unless the module is lazy loaded.
|
||||
Then it creates a _child injector_ and adds the module's providers to the child injector.
|
||||
|
||||
Angular会把`@NgModule.providers`中的提供商添加到应用的根注入器中……
|
||||
除非该模块是延迟加载的，这种情况下，它会创建一*子注入器*，并且把该模块的提供商添加到这个子注入器中。
|
||||
除非该模块是惰性加载的，这种情况下，它会创建一*子注入器*，并且把该模块的提供商添加到这个子注入器中。
|
||||
|
||||
This means that a module behaves differently depending on whether it is loaded during application start
|
||||
or lazy loaded later. Neglecting that difference can lead to [adverse consequences](#q-why-bad).
|
||||
|
||||
这意味着模块的行为将取决于它是在应用启动期间加载的还是后来延迟加载的。如果疏忽了这一点，可能导致[严重后果](#q-why-bad)。
|
||||
这意味着模块的行为将取决于它是在应用启动期间加载的还是后来惰性加载的。如果疏忽了这一点，可能导致[严重后果](#q-why-bad)。
|
||||
|
||||
Why doesn't Angular add lazy loaded providers to the app root injector as it does for eagerly loaded modules?
|
||||
Why the inconsistency?
|
||||
|
||||
为什么Angular不能像立即加载模块那样把延迟加载模块的提供商也添加到应用程序的根注入器中呢？为什么会出现这种不一致？
|
||||
为什么Angular不能像立即加载模块那样把惰性加载模块的提供商也添加到应用程序的根注入器中呢？为什么会出现这种不一致？
|
||||
|
||||
The answer is grounded in a fundamental characteristic of the Angular dependency injection system.
|
||||
An injector can add providers _until it is first used_.
|
||||
|
|
@ -937,10 +937,10 @@ a#q-why-child-injector
|
|||
It can't added them to the app root injector because that injector is closed to new providers.
|
||||
So Angular creates a new child injector for the lazy loaded module context.
|
||||
|
||||
之后，应用逻辑开始延迟加载某个模块。
|
||||
Angular必须把这个延迟加载模块中的提供商添加到*某个*注入器中。
|
||||
之后，应用逻辑开始惰性加载某个模块。
|
||||
Angular必须把这个惰性加载模块中的提供商添加到*某个*注入器中。
|
||||
但是它无法将它们添加到应用的根注入器中，因为根注入器已经不再接受新的提供商了。
|
||||
于是，Angular在延迟加载模块的上下文中创建了一个新的子注入器。
|
||||
于是，Angular在惰性加载模块的上下文中创建了一个新的子注入器。
|
||||
|
||||
.l-hr
|
||||
|
||||
|
|
@ -956,7 +956,7 @@ a#q-is-it-loaded
|
|||
that may be difficult to detect and diagnose.
|
||||
|
||||
某些模块及其服务只能被根模块`AppModule`加载一次。
|
||||
在延迟加载模块中再次导入这个模块会[导致错误的行为](#q-why-bad)，这个错误可能非常难于检测和诊断。
|
||||
在惰性加载模块中再次导入这个模块会[导致错误的行为](#q-why-bad)，这个错误可能非常难于检测和诊断。
|
||||
|
||||
We can guard against that danger by writing a constructor that attempts to inject the module or service
|
||||
from the root app injector. If the injection succeeds, the class has been loaded a second time.
|
||||
|
|
@ -1206,7 +1206,7 @@ a#q-module-recommendations
|
|||
Import the `SharedModule` in your _feature_ modules,
|
||||
both those loaded when the app starts and those you lazy load later.
|
||||
|
||||
在任何特性模块中（无论是你在应用启动时立即加载的模块还是之后延迟加载的模块），你都可以随意导入这个`SharedModule`。
|
||||
在任何特性模块中（无论是你在应用启动时立即加载的模块还是之后惰性加载的模块），你都可以随意导入这个`SharedModule`。
|
||||
|
||||
#### _CoreModule_
|
||||
Create a `CoreModule` with `providers` for the singleton services you load when the application starts.
|
||||
|
|
@ -1334,7 +1334,7 @@ table
|
|||
|
||||
All lazy loaded modules are routed feature modules by definition.
|
||||
|
||||
根据这个定义，所有延迟加载的模块都是路由特性模块。
|
||||
根据这个定义，所有惰性加载的模块都是路由特性模块。
|
||||
|
||||
This chapter's `ContactModule`, `HeroModule` and `CrisisModule` are routed feature modules.
|
||||
|
||||
|
|
@ -1349,9 +1349,9 @@ table
|
|||
Doing so would trigger an eager load, defeating the purpose of lazy loading.
|
||||
`HeroModule` and `CrisisModule` are lazy loaded. They aren't mentioned among the `AppModule` imports.
|
||||
|
||||
延迟加载的路由特性模块也不应该被任何模块*导出*。
|
||||
那么做会触发一次立即加载，破坏了我们延迟加载的目的。
|
||||
`HeroModule`和`CrisisModule`是延迟加载的。它们没有出现在`AppModule`的`imports`中。
|
||||
惰性加载的路由特性模块也不应该被任何模块*导出*。
|
||||
那么做会触发一次立即加载，破坏了我们惰性加载的目的。
|
||||
`HeroModule`和`CrisisModule`是惰性加载的。它们没有出现在`AppModule`的`imports`中。
|
||||
|
||||
But an eager loaded Routed Feature Module must be imported by another module
|
||||
so that the compiler learns about its components.
|
||||
|
|
@ -1784,15 +1784,15 @@ table
|
|||
A lazy loaded module has its own sub-root injector which typically
|
||||
is a direct child of the application root injector.
|
||||
|
||||
延迟加载模块有自己的子注入器，通常它是应用的根注入器的直接子级。
|
||||
惰性加载模块有自己的子注入器，通常它是应用的根注入器的直接子级。
|
||||
|
||||
Lazy loaded services are scoped to the lazy module's injector.
|
||||
If a lazy loaded module also provides the `HeroService`,
|
||||
any component created within that module's context (e.g., by router navigation)
|
||||
gets the local instance of the service, not the instance in the root application injector.
|
||||
|
||||
延迟加载的服务，其作用范围仅限于延迟加载模块的注入器中。
|
||||
如果延迟加载的模块也提供了`HeroService`，那么在该模块的环境中创建的任何组件（比如通过路由器导航），都会得到该服务的一个局部实例，而不是来自应用程序根注入器的那个全局实例。
|
||||
惰性加载的服务，其作用范围仅限于惰性加载模块的注入器中。
|
||||
如果惰性加载的模块也提供了`HeroService`，那么在该模块的环境中创建的任何组件（比如通过路由器导航），都会得到该服务的一个局部实例，而不是来自应用程序根注入器的那个全局实例。
|
||||
|
||||
Components in external modules continue to receive the instance created for the application root.
|
||||
|
||||
|
|
|
|||
|
|
@ -558,7 +558,7 @@
|
|||
"bold": [
|
||||
"CanLoad"
|
||||
],
|
||||
"description": "<p>一个用来定义类的接口，路由器会首先调用它来决定一个延迟加载的模块是否应该被加载。应该返回布尔值或能解析为布尔值的可观察对象(Observable)或承诺(Promise)。</p>\n"
|
||||
"description": "<p>一个用来定义类的接口，路由器会首先调用它来决定一个惰性加载的模块是否应该被加载。应该返回布尔值或能解析为布尔值的可观察对象(Observable)或承诺(Promise)。</p>\n"
|
||||
}
|
||||
],
|
||||
"index": 11
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ block includes
|
|||
* [Feature modules](#feature-modules "Partition the app into feature modules")
|
||||
* [特性模块](#feature-modules "把应用分割成一些特性模块")
|
||||
* [Lazy loaded modules](#lazy-load "Load modules asynchronously") with the Router
|
||||
* 通过路由器[延迟加载模块](#lazy-load "延迟加载模块")
|
||||
* 通过路由器[惰性加载模块](#lazy-load "惰性加载模块")
|
||||
* [Shared modules](#shared-module "Create modules for commonly used components, directives, and pipes")
|
||||
* [共享模块](#shared-module "为公用的组件、指令和管道创建模块")
|
||||
* [The Core module](#core-module "Create a core module with app-wide singleton services and single-use components")
|
||||
|
|
@ -57,7 +57,7 @@ block includes
|
|||
* [Configure core services with _forRoot_](#core-for-root "Configure providers during module import")
|
||||
* [用_forRoot_配置核心服务](#core-for-root "在导入模块时配置提供商")
|
||||
* [Prevent reimport of the _CoreModule_](#prevent-reimport "because bad things happen if a lazy loaded module imports Core")
|
||||
* [禁止重复导入_CoreModule_](#prevent-reimport "如果延迟加载模块导入了核心模块，就会出问题")
|
||||
* [禁止重复导入_CoreModule_](#prevent-reimport "如果惰性加载模块导入了核心模块，就会出问题")
|
||||
* [NgModule metadata properties](#ngmodule-properties "A technical summary of the @NgModule metadata properties")
|
||||
* [NgModule元数据的属性](#ngmodule-properties "对@NgModule元数据属性的技术性总结")
|
||||
|
||||
|
|
@ -132,7 +132,7 @@ a#angular-modularity
|
|||
Modules can be loaded eagerly when the application starts.
|
||||
They can also be _lazy loaded_ asynchronously by the router.
|
||||
|
||||
模块可能在应用启动时立即加载，也可能由路由器进行异步_延迟加载_。
|
||||
模块可能在应用启动时立即加载，也可能由路由器进行异步_惰性加载_。
|
||||
|
||||
An Angular module is a class decorated with `@NgModule` metadata. The metadata:
|
||||
|
||||
|
|
@ -1161,7 +1161,7 @@ a#lazy-load
|
|||
|
||||
* `HeroModule` and the `CrisisModule` are lazy loaded.
|
||||
|
||||
* `HeroModule`和`CrisisModule`会被延迟加载。
|
||||
* `HeroModule`和`CrisisModule`会被惰性加载。
|
||||
|
||||
<a id="app-component-template"></a>
|
||||
|
||||
|
|
@ -1242,7 +1242,7 @@ a#lazy-load
|
|||
|
||||
The remaining two routes use lazy loading syntax to tell the router where to find the modules:
|
||||
|
||||
另外两个路由使用延迟加载语法来告诉路由器要到哪里去找这些模块。
|
||||
另外两个路由使用惰性加载语法来告诉路由器要到哪里去找这些模块。
|
||||
|
||||
+makeExample('ngmodule/ts/app/app.routing.ts', 'lazy-routes')(format='.')
|
||||
|
||||
|
|
@ -1252,7 +1252,7 @@ a#lazy-load
|
|||
In this app, the string identifies both the module _file_ and the module _class_,
|
||||
the latter separated from the former by a `#`.
|
||||
|
||||
延迟加载模块的位置是*字符串*而不是*类型*。
|
||||
惰性加载模块的位置是*字符串*而不是*类型*。
|
||||
在本应用中，该字符串同时标记出了模块*文件*和模块*类*，两者用`#`分隔开。
|
||||
|
||||
:marked
|
||||
|
|
@ -1358,12 +1358,12 @@ a#hero-module
|
|||
:marked
|
||||
### Lazy loaded routing to a module
|
||||
|
||||
### 路由到延迟加载的模块
|
||||
### 路由到惰性加载的模块
|
||||
|
||||
The lazy loaded `HeroModule` and `CrisisModule` follow the same principles as any feature module.
|
||||
They don't look different from the eagerly loaded `ContactModule`.
|
||||
|
||||
延迟加载的`HeroModule`和`CrisisModule`与其它特性模块遵循同样的规则。它们和“立即加载”的`ContactModule`看上去没有任何区别。
|
||||
惰性加载的`HeroModule`和`CrisisModule`与其它特性模块遵循同样的规则。它们和“立即加载”的`ContactModule`看上去没有任何区别。
|
||||
|
||||
The `HeroModule` is a bit more complex than the `CrisisModule` which makes it
|
||||
a more interesting and useful example. Here's its file structure:
|
||||
|
|
@ -1542,7 +1542,7 @@ a#shared-module
|
|||
A lazy loaded module that imports that shared module will make its own copy of the service.
|
||||
|
||||
**不要**在共享模块中把应用级单例添加到`providers`中。
|
||||
否则如果一个延迟加载模块导入了此共享模块，就会导致它自己也生成一份此服务的实例。
|
||||
否则如果一个惰性加载模块导入了此共享模块，就会导致它自己也生成一份此服务的实例。
|
||||
|
||||
a#core-module
|
||||
.l-main-section
|
||||
|
|
@ -1602,7 +1602,7 @@ a#core-module
|
|||
making a singleton instance of the `UserService` available to any component that needs it,
|
||||
whether that component is eagerly or lazily loaded.
|
||||
|
||||
`CoreModule`*提供*了`UserService`。Angular在该应用的“根注入器”中注册了它的提供商，导致这份`UserService`的实例在每个需要它的组件中都是可用的，无论那个组件时立即加载的还是延迟加载的。
|
||||
`CoreModule`*提供*了`UserService`。Angular在该应用的“根注入器”中注册了它的提供商，导致这份`UserService`的实例在每个需要它的组件中都是可用的，无论那个组件时立即加载的还是惰性加载的。
|
||||
|
||||
.l-sub-section
|
||||
:marked
|
||||
|
|
@ -1791,7 +1791,7 @@ a#core-for-root
|
|||
is contrary to the intent and is likely to produce a runtime error.
|
||||
|
||||
只在应用的根模块`AppModule`中调用`forRoot`。
|
||||
如果在其它模块（特别是延迟加载模块）中调用它则违反了设计意图，并会导致运行时错误。
|
||||
如果在其它模块（特别是惰性加载模块）中调用它则违反了设计意图，并会导致运行时错误。
|
||||
|
||||
Remember to _import_ the result; don't add it to any other `@NgModule` list.
|
||||
|
||||
|
|
@ -1810,7 +1810,7 @@ a#prevent-reimport
|
|||
[Bad things happen](../cookbook/ngmodule-faq.html#q-why-it-is-bad) if a lazy loaded module imports it.
|
||||
|
||||
只有根模块`AppModule`才能导入`CoreModule`。
|
||||
如果延迟加载模块导入了它，就会[出问题](../cookbook/ngmodule-faq.html#q-why-it-is-bad)。
|
||||
如果惰性加载模块导入了它，就会[出问题](../cookbook/ngmodule-faq.html#q-why-it-is-bad)。
|
||||
|
||||
We could _hope_ that no developer makes that mistake.
|
||||
Or we can guard against it and fail fast by adding the following `CoreModule` constructor.
|
||||
|
|
@ -1849,14 +1849,14 @@ a#prevent-reimport
|
|||
|
||||
It's a different story if we improperly import `CoreModule` into a lazy loaded module such as `HeroModule` (try it).
|
||||
|
||||
如果我们错误的把`CoreModule`导入了一个延迟加载模块（比如`HeroModule`）中，那就不一样了。
|
||||
如果我们错误的把`CoreModule`导入了一个惰性加载模块（比如`HeroModule`）中，那就不一样了。
|
||||
|
||||
Angular creates a lazy loaded module with its own injector, a _child_ of the root injector.
|
||||
`@SkipSelf` causes Angular to look for a `CoreModule` in the parent injector which this time is the root injector.
|
||||
Of course it finds the instance imported by the root `AppModule`.
|
||||
Now `parentModule` exists and the constructor throws the error.
|
||||
|
||||
Angular创建一个延迟加载模块，它具有自己的注入器，它是根注入器的*子注入器*。
|
||||
Angular创建一个惰性加载模块，它具有自己的注入器，它是根注入器的*子注入器*。
|
||||
`@SkipSelf`让Angular在其父注入器中查找`CoreModule`，这次，它的父注入器却是根注入器了（而上次父注入器是空）。
|
||||
当然，这次它找到了由根模块`AppModule`导入的实例。
|
||||
该构造函数检测到存在`parentModule`，于是抛出一个错误。
|
||||
|
|
|
|||
|
|
@ -750,7 +750,7 @@ figure.image-display
|
|||
|
||||
* lazy loading feature modules
|
||||
|
||||
* 延迟加载特性路由
|
||||
* 惰性加载特性路由
|
||||
|
||||
* the `CanLoad` guard (check before loading feature module assets)
|
||||
|
||||
|
|
@ -2376,7 +2376,7 @@ a#child-routing-component
|
|||
We can load it optionally, [asynchronously](#asynchronous-routing) with the other *Crisis Center* components
|
||||
if and when the user begins that workflow.
|
||||
|
||||
第二，可以对此服务进行延迟加载，直到需要它的时候才加载到内存中。
|
||||
第二，可以对此服务进行惰性加载，直到需要它的时候才加载到内存中。
|
||||
可以从应用的发布包中移除它，以减小首次加载的体积并提升性能。
|
||||
可以用可选的方式加载它，当用户开始此工作流时，本应用才异步加载其它的*危机中心*组件。
|
||||
:marked
|
||||
|
|
@ -3544,7 +3544,7 @@ a#fragment
|
|||
:marked
|
||||
### Lazy-Loading route configuration
|
||||
|
||||
### 懒惰加载路由配置
|
||||
### 惰性加载路由配置
|
||||
|
||||
We'll start by adding an `admin` route to our `app.routing.ts` file. We want to load our `Admin` module asynchronously,
|
||||
so we'll use the `loadChildren` property in our route config where previously we used the `children` property to include our child routes.
|
||||
|
|
@ -3577,7 +3577,7 @@ a#fragment
|
|||
:marked
|
||||
The `loadChildren` property is used by the `Router` to map to our bundle we want to lazy-load, in this case being the `AdminModule`.
|
||||
|
||||
路由器用`loadChildren`属性来映射我们希望延迟加载的捆文件，这里是`AdminModule`。
|
||||
路由器用`loadChildren`属性来映射我们希望惰性加载的捆文件，这里是`AdminModule`。
|
||||
|
||||
If we look closer at the `loadChildren` string, we can see that it maps directly to our `admin.module.ts` file where we previously built
|
||||
out our `Admin` feature area. After the path to the file we use a `#` to denote where our file path ends and to tell the `Router` the name
|
||||
|
|
@ -3593,7 +3593,7 @@ a#fragment
|
|||
and then load the requested route. This will only happen when the route is **first** requested and the module will be immediately be available
|
||||
for subsequent requests.
|
||||
|
||||
路由器用`loadChildren`属性来映射我们希望延迟加载的捆文件，这里是`AdminModule`。路由器将接收我们的`loadChildren`字符串，并把它动态加载进`AdminModule`，它的路由被*动态*合并到我们的配置中，然后加载所请求的路由。但只有在首次加载该路由时才会这样做，后续的请求都会立即完成。
|
||||
路由器用`loadChildren`属性来映射我们希望惰性加载的捆文件，这里是`AdminModule`。路由器将接收我们的`loadChildren`字符串，并把它动态加载进`AdminModule`，它的路由被*动态*合并到我们的配置中，然后加载所请求的路由。但只有在首次加载该路由时才会这样做，后续的请求都会立即完成。
|
||||
|
||||
.l-sub-section
|
||||
:marked
|
||||
|
|
@ -3607,7 +3607,7 @@ a#fragment
|
|||
to break our `AdminModule` into a completely separate module. In our `app.module.ts`, we'll remove our `AdminModule` from the
|
||||
`imports` array since we'll be loading it on-demand an we'll remove the imported `AdminModule`.
|
||||
|
||||
我们构建了特性区，更新了路由配置来实现懒惰加载，现在该做最后一步：将`CrisisCenterModule`分离到一个彻底独立的模块。因为现在按需加载`CrisisCenterModule`，所以在`app.module.ts`中，从`imports`数组中删除它。
|
||||
我们构建了特性区，更新了路由配置来实现惰性加载，现在该做最后一步：将`CrisisCenterModule`分离到一个彻底独立的模块。因为现在按需加载`CrisisCenterModule`，所以在`app.module.ts`中，从`imports`数组中删除它。
|
||||
|
||||
+makeExcerpt('app/app.module.ts (async admin module)', '')
|
||||
|
||||
|
|
|
|||
|
|
@ -1749,7 +1749,7 @@ a(href="#toc") 回到顶部
|
|||
:marked
|
||||
**Why?** Angular modules make it easy to lazy load routable features.
|
||||
|
||||
**为何？**Angular模块能让对可路由的特性进行延迟加载变得更容易。
|
||||
**为何？**Angular模块能让对可路由的特性进行惰性加载变得更容易。
|
||||
|
||||
.s-why.s-why-last
|
||||
:marked
|
||||
|
|
@ -1850,7 +1850,7 @@ a(href="#toc") Back to top
|
|||
:marked
|
||||
**Why?** A feature module can easily be routed to both eagerly and lazily.
|
||||
|
||||
**为何？**特性模块能很容易的被路由器加载 —— 无论使用提前加载还是延迟加载的方式。
|
||||
**为何？**特性模块能很容易的被路由器加载 —— 无论使用提前加载还是惰性加载的方式。
|
||||
|
||||
.s-why
|
||||
:marked
|
||||
|
|
@ -1933,7 +1933,7 @@ a(href="#toc") 回到顶部
|
|||
: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
|
||||
|
|
@ -2020,13 +2020,13 @@ a(href="#toc") 回到顶部
|
|||
:marked
|
||||
**Why?** `CoreModule` provides one or more singleton services. Angular registers the providers with the app root injector, making a singleton instance of each service available to any component that needs them, whether that component is eagerly or lazily loaded.
|
||||
|
||||
**为何？** `CoreModule`提供了一个或多个单例服务。Angular使用应用的根注入器注册这些服务提供商，让每个服务的这个单例对象对所有需要它们的组件都是可用的，而不用管该组件是通过立即加载还是延迟加载的方式加载的。
|
||||
**为何？** `CoreModule`提供了一个或多个单例服务。Angular使用应用的根注入器注册这些服务提供商，让每个服务的这个单例对象对所有需要它们的组件都是可用的，而不用管该组件是通过立即加载还是惰性加载的方式加载的。
|
||||
|
||||
.s-why
|
||||
:marked
|
||||
**Why?** `CoreModule` will contain singleton services. When a lazy loaded module imports these, it will get a new instance and not the intended app-wide singleton.
|
||||
|
||||
**为何？**`CoreModule`将包含一些单例服务。而如果延迟加载模块导入这些服务，它就会得到一个新实例，而不是所期望的全应用级单例。
|
||||
**为何？**`CoreModule`将包含一些单例服务。而如果惰性加载模块导入这些服务，它就会得到一个新实例，而不是所期望的全应用级单例。
|
||||
|
||||
.s-rule.do
|
||||
:marked
|
||||
|
|
@ -2055,7 +2055,7 @@ a(href="#toc") 回到顶部
|
|||
:marked
|
||||
**Why?** A lazily loaded feature module that directly imports the `CoreModule` will make its own copy of services and likely have undesireable results.
|
||||
|
||||
**为何？**如果延迟加载的特性模块直接导入`CoreModule`，就会创建它自己的服务副本，并导致意料之外的后果。
|
||||
**为何？**如果惰性加载的特性模块直接导入`CoreModule`，就会创建它自己的服务副本，并导致意料之外的后果。
|
||||
|
||||
.s-why
|
||||
:marked
|
||||
|
|
@ -2247,20 +2247,20 @@ a(href="#toc") 回到顶部
|
|||
.l-main-section
|
||||
:marked
|
||||
### <a id="04-13"></a>Lazy Loaded Folders
|
||||
### <a id="04-13"></a>延迟加载的目录
|
||||
### <a id="04-13"></a>惰性加载的目录
|
||||
#### <a href="#04-13">Style 04-13</a>
|
||||
#### <a href="#04-13">样式04-13</a>
|
||||
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
|
||||
|
|
@ -2275,7 +2275,7 @@ a(href="#toc") 回到顶部
|
|||
.l-main-section
|
||||
:marked
|
||||
### <a id="04-14"></a>Never Directly Import Lazy Loaded Folders
|
||||
### <a id="04-14"></a>永远不要直接导入延迟加载的目录
|
||||
### <a id="04-14"></a>永远不要直接导入惰性加载的目录
|
||||
#### <a href="#04-14">Style 04-14</a>
|
||||
#### <a href="#04-14">样式04-14</a>
|
||||
|
||||
|
|
@ -2283,7 +2283,7 @@ a(href="#toc") 回到顶部
|
|||
: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
|
||||
|
|
|
|||
Loading…
Reference in New Issue