doc(compiler): ivy seperate compilation design document#22480
doc(compiler): ivy seperate compilation design document#22480chuckjaz wants to merge 9 commits intoangular:masterfrom
Conversation
|
You can preview e25c865 at https://pr22480-e25c865.ngbuilds.io/. |
There was a problem hiding this comment.
providers should be ngInjectorDef?
viewProviders should be ngComponentDef?
e25c865 to
bc954a7
Compare
|
You can preview bc954a7 at https://pr22480-bc954a7.ngbuilds.io/. |
| @NgModule({ | ||
| imports: [CommonModule, UtilityModule], | ||
| declarations: [MyComponent, MyDirective, MyComponent], | ||
| exports: [MyComponent, MyDirective, MyComponent, UtilityModule], |
| dependencies change, their factories would be invalid preventing them from | ||
| version ranges in their dependencies. To support producing factories from | ||
| compiled source (already translated by TypeScript into JavaScript) | ||
| libraries include metadata that describe the content of the the Angular |
| the decorator can be thought of as parameters to a class transformer that | ||
| transforms the information in the decorator into the corresponding | ||
| definition. An `@Component` decorator transforms the class by adding | ||
| an `ngComponentDef` static variable, `@Directive` adds `ngDirectiveDef`, |
There was a problem hiding this comment.
static property instead of static variable?
| ## Information needed | ||
|
|
||
| The information available across compilations in Angular 5 is represented in | ||
| the compiler by a summary description. For example, components and directive |
There was a problem hiding this comment.
components and directive -> components and directives? Both plural?
| The only pieces of information that are not generated into the definition are | ||
| the directive selector and the pipe name as they go into the module scope. | ||
|
|
||
| The information needed to build a `ngModuleScope` needs to be communicated |
| ### Angular 5 | ||
|
|
||
| Angular 5 uses `.metadata.json` files to store information that is directly | ||
| inferred form the `.ts` files and include value information that is not |
| types are included in `.d.ts` files and might not include the exports necessary | ||
| for values, the metadata includes export clauses from the `.ts` file. | ||
|
|
||
| When a module is flattened into a FESM (Flat EcmaScript Module), a flat |
| ```ts | ||
| @Component({ | ||
| selector: 'my-comp', | ||
| template: `<h1>Hello, {{name}}!` |
There was a problem hiding this comment.
Ouch. The compiler in my head is broken.
| the metadata necessary to generate the factories, they cannot contain, | ||
| themselves, the generated factories. This is because, if any of there | ||
| dependencies change, their factories would be invalid preventing them from | ||
| version ranges in their dependencies. To support producing factories from |
There was a problem hiding this comment.
ranges. You would be required to specify exact versions as you could not tolerate even a point release change.
| ### Angular Ivy | ||
|
|
||
| In Ivy, the runtime is crafted in a way that allows for separate compilation | ||
| by preforming at runtime much of what was previously pre-calculated by |
| compiler. This allows the definition of components to change without | ||
| requiring modules and components that depend on them being recompiled. | ||
|
|
||
| The mental model of Ivy is that the decorator is the compiler. That is |
There was a problem hiding this comment.
"the decorator is the compiler" I am not a fan of this terminology. Doesn't it bring some confusion ?
There was a problem hiding this comment.
It is the model we want to eventually have. That is, we want the decorator to be a class transformer. A transformer is a compiler.
There was a problem hiding this comment.
It is the model we want to eventually have. That is, we want the decorator to be a class transformer. A transformer is a compiler.
I understand the concept. However IMO saying "the decorator is the compiler" without further explanation is confusing. I also find "class transformer" confusing here wrt to TS transformer.
I am not saying that anything is wrong only that it deserves some more explanation.
| interpreting the template, the compiler needs to know the selector defined for | ||
| each component, directive and pipe that are in scope of the template. The | ||
| purpose of this document is to define what information is needed by the | ||
| compiler that is not provided by the decorator, is serialized, discovered and |
There was a problem hiding this comment.
ie "what information is needed by the compiler that is not provided by the decorator" -> you just told me that the compiler is the decorator
There was a problem hiding this comment.
Also I am not sure to understand this sentence
| *my.component.ts* | ||
| ```js | ||
| export class MyComponent { | ||
| name: string; |
There was a problem hiding this comment.
No. We don't emit the ngSelector, it is only present in the metadata. Or, you can think of it as, we pre-remove it. "Manual considerations" below describes how to get build optimizer to remove it for you if you define the component manually.
| constructor() { | ||
| this.dirId = 'some id'; | ||
| } | ||
| static ngDirectiveDef = defineDirective({...}); |
| ### Angular 5 | ||
|
|
||
| In 5.0 and prior versions of Angular the compiler performs whole program | ||
| analysis and generates template and injector definitions that are use |
There was a problem hiding this comment.
I believe this was meant to read "injector definitions that are using this global knowledge".
| Separate component and module compilation is supported only at the module | ||
| definition level and only from source. That is, npm packages must contain | ||
| the metadata necessary to generate the factories, they cannot contain, | ||
| themselves, the generated factories. This is because, if any of there |
There was a problem hiding this comment.
Once again, "if any of their dependencies change".
| The metadata for a module is transformed by: | ||
|
|
||
| 1. Remove the `@NgModule` directive. | ||
| 2. Add `"ngPipeDef": {}` static field. |
There was a problem hiding this comment.
Did you mean ngInjectorDef?
|
You can preview 8e79432 at https://pr22480-8e79432.ngbuilds.io/. |
| ```js | ||
| export class MyComponent { | ||
| name: string; | ||
| static ngComponentDef = defineComponent({...}); |
There was a problem hiding this comment.
wrt to my comment about ngSelector I understand what you mean. But how does it fit with l138.
Needs more explanation ?
There was a problem hiding this comment.
This document only describes the metadata so 138 describing the transforms to the metadata, not the source. The source is only included here for illustration.
| export class MyPipe { | ||
| transform(...) ... | ||
| static ngPipeDef = definePipe({...}); | ||
| static ngSelector = 'myPipe'; |
There was a problem hiding this comment.
Why do we have ngSelector here ? (cf my comment about more explanation)
There was a problem hiding this comment.
It shouldn't have been. Removed.
|
|
||
| The mental model of Ivy is that the decorator is the compiler. That is | ||
| the decorator can be thought of as parameters to a class transformer that | ||
| transforms the information in the decorator into the corresponding |
There was a problem hiding this comment.
"transforms" here is confusing wrt "class transformer".
May be rephrase to say that it transforms the class by generating definitions based on the decorator parameters ?
| interpreting the template, the compiler needs to know the selector defined for | ||
| each component, directive and pipe that are in scope of the template. The | ||
| purpose of this document is to define what information is needed by the | ||
| compiler that is not provided by the decorator is serialized, discovered and |
There was a problem hiding this comment.
still does not understand this sentence ? "by the decorator is serialized"
|
You can preview 9a16b64 at https://pr22480-9a16b64.ngbuilds.io/. |
|
|
||
| ### `CompileDirectiveSummary` | ||
|
|
||
| | field | ivy | |
There was a problem hiding this comment.
find better description for those headers ? (field and ivy)
| understood by the compiler. | ||
|
|
||
| Unfortunately, however, manually generated module contain references to | ||
| classes that might not be necessary at runtime. Manually or third-party |
There was a problem hiding this comment.
Manually or third-party ...
I would rephrase this
Something like:
"Manually or third-party components can get the same [...] by removing the the ngSelector and ngModuleScope properties. When using the build optimizer (add link) this can be achieved by ..."
There was a problem hiding this comment.
This would imply that could just not have it which is exactly the opposite think I am trying to convey.
|
|
||
| ## Background | ||
|
|
||
| ### Angular 5 |
There was a problem hiding this comment.
"Angular 5" -> "Render2" ? May be a quick description of what those terms means in this background section would be great.
| ### Application output | ||
|
|
||
| The output of the ivy compiler only optionally generates the factories | ||
| generated by the Render2 style output of Angular 5.0. In Ivy, the information |
There was a problem hiding this comment.
use "ivy" or "Ivy" consistently
|
|
||
| The output of the ivy compiler only optionally generates the factories | ||
| generated by the Render2 style output of Angular 5.0. In Ivy, the information | ||
| that was generated in factories is now generated in Angular a definition that |
There was a problem hiding this comment.
"in Angular a definition" typo
|
|
||
| ##### example - ivy package | ||
|
|
||
| Ivy packages are not supported in Angular 6.0 as they are not recommended as |
|
Very nice updates ! |
|
You can preview eb93dce at https://pr22480-eb93dce.ngbuilds.io/. |
|
You can preview 78edab8 at https://pr22480-78edab8.ngbuilds.io/. |
|
You can preview 39f67a3 at https://pr22480-39f67a3.ngbuilds.io/. |
| The purpose of the "package" target is to produce a library package that will | ||
| be an entry point for an npm package. Each entry point should be separately | ||
| compiled using a "package" target. Note that this makes explicit the limitation | ||
| that a module from a package cannot be directly lazily loaded. It must be |
There was a problem hiding this comment.
maybe add , because theres is nothing which will trigger the generation of the factory files
|
You can preview 8dcdb91 at https://pr22480-8dcdb91.ngbuilds.io/. |
|
|
||
| #### `ivy_sources` | ||
|
|
||
| The `ivy_sources` can be used as use to cause the ivy versions of files to be |
There was a problem hiding this comment.
This section is confusing. Could you add an example code, I think that would make it more clear.
|
You can preview cfbbcf9 at https://pr22480-cfbbcf9.ngbuilds.io/. |
Produces back-patch as described in the angular#22235 and referenced in angular#22480. This just contains the compiler implementations and the corresponding unit tests. Connecting the dots as described in angular#22480 will be in a follow on change.
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
PR Type
What kind of change does this PR introduce?
Design document for how the ivy compiler will handle metadata for separate compilation.
Does this PR introduce a breaking change?