iSharkFly-Docs/angular-docs-cn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
angular-docs-cn/packages/core/src/r3_symbols.ts

39 lines
1.6 KiB
TypeScript
Raw Normal View History

feat(ivy): able to compile @angular/core with ngtsc (#24677) @angular/core is unique in that it defines the Angular decorators (@Component, @Directive, etc). Ordinarily ngtsc looks for imports from @angular/core in order to identify these decorators. Clearly within core itself, this strategy doesn't work. Instead, a special constant ITS_JUST_ANGULAR is declared within a known file in @angular/core. If ngtsc sees this constant it knows core is being compiled and can ignore the imports when evaluating decorators. Additionally, when compiling decorators ngtsc will often write an import to @angular/core for needed symbols. However @angular/core cannot import itself. This change creates a module within core to export all the symbols needed to compile it and adds intelligence within ngtsc to write relative imports to that module, instead of absolute imports to @angular/core. PR Close #24677
2018-06-20 15:54:16 -07:00
/**
* @license
* Copyright Google Inc. All Rights Reserved.
*
* Use of this source code is governed by an MIT-style license that can be
* found in the LICENSE file at https://angular.io/license
*/
/*
* This file exists to support compilation of @angular/core in Ivy mode.
*
* When the Angular compiler processes a compilation unit, it normally writes imports to
* @angular/core. When compiling the core package itself this strategy isn't usable. Instead, the
* compiler writes imports to this file.
*
* Only a subset of such imports are supported - core is not allowed to declare components or pipes.
refactor(ivy): extract import rewriting into a separate interface (#27998) Currently the ImportManager class handles various rewriting actions of imports when compiling @angular/core. This is required as code compiled within @angular/core cannot import from '@angular/core'. To work around this, imports are rewritten to get core symbols from a particular file, r3_symbols.ts. In this refactoring, this rewriting logic is moved out of the ImportManager and put behind an interface, ImportRewriter. There are three implementers of the interface: * NoopImportRewriter, used for compiling all non-core packages. * R3SymbolsImportRewriter, used when ngtsc compiles @angular/core. * NgccFlatImportRewriter, used when ngcc compiles @angular/core (special logic is needed because ngcc has to rewrite imports in flat bundles differently than in non-flat bundles). This is a precursor to using this rewriting logic in other contexts besides the ImportManager. PR Close #27998
2019-01-08 11:49:58 -08:00
* A check in ngtsc's `R3SymbolsImportRewriter` validates this condition. The rewriter is only used
* when compiling @angular/core and is responsible for translating an external name (prefixed with
* ɵ) to the internal symbol name as exported below.
feat(ivy): able to compile @angular/core with ngtsc (#24677) @angular/core is unique in that it defines the Angular decorators (@Component, @Directive, etc). Ordinarily ngtsc looks for imports from @angular/core in order to identify these decorators. Clearly within core itself, this strategy doesn't work. Instead, a special constant ITS_JUST_ANGULAR is declared within a known file in @angular/core. If ngtsc sees this constant it knows core is being compiled and can ignore the imports when evaluating decorators. Additionally, when compiling decorators ngtsc will often write an import to @angular/core for needed symbols. However @angular/core cannot import itself. This change creates a module within core to export all the symbols needed to compile it and adds intelligence within ngtsc to write relative imports to that module, instead of absolute imports to @angular/core. PR Close #24677
2018-06-20 15:54:16 -07:00
*
* The below symbols are used for @Injectable and @NgModule compilation.
*/
refactor(ivy): Move instructions back to ɵɵ (#30546) There is an encoding issue with using delta `Δ`, where the browser will attempt to detect the file encoding if the character set is not explicitly declared on a `<script/>` tag, and Chrome will find the `Δ` character and decide it is window-1252 encoding, which misinterprets the `Δ` character to be some other character that is not a valid JS identifier character So back to the frog eyes we go. ``` __ /ɵɵ\ ( -- ) - I am ineffable. I am forever. _/ \_ / \ / \ == == == ``` PR Close #30546
2019-05-17 18:49:21 -07:00
export {ɵɵinject} from './di/injector_compatibility';
export {ɵɵInjectableDef, ɵɵInjectorDef, ɵɵdefineInjectable, ɵɵdefineInjector} from './di/interface/defs';
export {NgModuleDef, ɵɵNgModuleDefWithMeta} from './metadata/ng_module';
export {ɵɵdefineNgModule} from './render3/definition';
refactor(ivy): generate ngFactoryDef for injectables (#32433) With #31953 we moved the factories for components, directives and pipes into a new field called `ngFactoryDef`, however I decided not to do it for injectables, because they needed some extra logic. These changes set up the `ngFactoryDef` for injectables as well. For reference, the extra logic mentioned above is that for injectables we have two code paths: 1. For injectables that don't configure how they should be instantiated, we create a `factory` that proxies to `ngFactoryDef`: ``` // Source @Injectable() class Service {} // Output class Service { static ngInjectableDef = defineInjectable({ factory: () => Service.ngFactoryFn(), }); static ngFactoryFn: (t) => new (t || Service)(); } ``` 2. For injectables that do configure how they're created, we keep the `ngFactoryDef` and generate the factory based on the metadata: ``` // Source @Injectable({ useValue: DEFAULT_IMPL, }) class Service {} // Output export class Service { static ngInjectableDef = defineInjectable({ factory: () => DEFAULT_IMPL, }); static ngFactoryFn: (t) => new (t || Service)(); } ``` PR Close #32433
2019-09-01 12:26:04 +02:00
export {ɵɵFactoryDef} from './render3/interfaces/definition';
fix(ivy): prevent ngcc from referencing missing ɵsetClassMetadata (#27055) When ngtsc compiles @angular/core, it rewrites core imports to the r3_symbols.ts file that exposes all internal symbols under their external name. When creating the FESM bundle, the r3_symbols.ts file causes the external symbol names to be rewritten to their internal name. Under ngcc compilations of FESM bundles, the indirection of r3_symbols.ts is no longer in place such that the external names are retained in the bundle. Previously, the external name `ɵdefineNgModule` was explicitly declared internally to resolve this issue, but the recently added `setClassMetadata` was not declared as such, causing runtime errors. Instead of relying on the r3_symbols.ts file to perform the rewrite of the external modules to their internal variants, the translation is moved into the `ImportManager` during the compilation itself. This avoids the need for providing the external name manually. PR Close #27055
2018-11-11 19:16:04 +01:00
export {setClassMetadata} from './render3/metadata';
export {NgModuleFactory} from './render3/ng_module_ref';
feat(ivy): able to compile @angular/core with ngtsc (#24677) @angular/core is unique in that it defines the Angular decorators (@Component, @Directive, etc). Ordinarily ngtsc looks for imports from @angular/core in order to identify these decorators. Clearly within core itself, this strategy doesn't work. Instead, a special constant ITS_JUST_ANGULAR is declared within a known file in @angular/core. If ngtsc sees this constant it knows core is being compiled and can ignore the imports when evaluating decorators. Additionally, when compiling decorators ngtsc will often write an import to @angular/core for needed symbols. However @angular/core cannot import itself. This change creates a module within core to export all the symbols needed to compile it and adds intelligence within ngtsc to write relative imports to that module, instead of absolute imports to @angular/core. PR Close #24677
2018-06-20 15:54:16 -07:00
feat(ivy): setClassMetadata() for assigning decorator metadata (#26860) This commit introduces the setClassMetadata() private function, which adds metadata to a type in a way that can be accessed via Angular's ReflectionCapabilities. Currently, it writes to static fields as if the metadata being added was downleveled from decorators by tsickle. The plan is for ngtsc to emit code which calls this function, passing metadata on to the runtime for testing purposes. Calls to this function would then be tree-shaken away for production bundles. Testing strategy: proper operation of this function will be an integral part of TestBed metadata overriding. Angular core tests will fail if this is broken. PR Close #26860
2018-10-30 10:16:52 -07:00
build: extract interface and util sub compilation from core (#28028) PR Close #28028
2019-01-09 13:49:16 -08:00
feat(ivy): able to compile @angular/core with ngtsc (#24677) @angular/core is unique in that it defines the Angular decorators (@Component, @Directive, etc). Ordinarily ngtsc looks for imports from @angular/core in order to identify these decorators. Clearly within core itself, this strategy doesn't work. Instead, a special constant ITS_JUST_ANGULAR is declared within a known file in @angular/core. If ngtsc sees this constant it knows core is being compiled and can ignore the imports when evaluating decorators. Additionally, when compiling decorators ngtsc will often write an import to @angular/core for needed symbols. However @angular/core cannot import itself. This change creates a module within core to export all the symbols needed to compile it and adds intelligence within ngtsc to write relative imports to that module, instead of absolute imports to @angular/core. PR Close #24677
2018-06-20 15:54:16 -07:00
/**
* The existence of this constant (in this particular file) informs the Angular compiler that the
* current program is actually @angular/core, which needs to be compiled specially.
*/
export const ITS_JUST_ANGULAR = true;
Reference in New Issue Copy Permalink