Support import() syntax for loadChildren in ViewEngine#13948
Conversation
|
Blocked on angular/angular#29392 |
import() syntax for loadChildren in ViewEngine
07b7772 to
8b10696
Compare
2a37c0c to
451d2cb
Compare
451d2cb to
2d7022f
Compare
| nameLazyFiles?: boolean; | ||
| logger?: logging.Logger; | ||
| directTemplateLoading?: boolean; | ||
| discoverLazyRoutes?: boolean; |
There was a problem hiding this comment.
Can you kindly explain the reasoning behind this option?
There was a problem hiding this comment.
When using the loadChildren string syntax, @ngtools/webpack must query @angular/compiler-cli via a private API to know which lazy routes exist. This increases build and rebuild time.
When using Ivy, the string syntax is not supported at all. Thus we shouldn't attempt that.
This commit also exists in #13700 for slightly different reasons. There, it is meant to disable this sort of processing for compilations that do not need it.
There was a problem hiding this comment.
Thanks for the clarification, it makes more sense now :) As to disable lazy route discovery under ivy we can use enableIvy, but seeing that other PR. I can now see the use case.
There was a problem hiding this comment.
Should we warn (or probably error) in the transformer (or somewhere else) if the string form is found when this option is off?
Users may not know why their applications are not working.
There was a problem hiding this comment.
I think not because that means we need to always check, which incurs a performance penalty on every AOT build.
The "right way" of doing that probably a Ivy migration when it's stable.
There was a problem hiding this comment.
let's try to generally answer questions like this in the form of a comment in the code - no one later will find this thread
| return replaceImport(node, context, emitWarning); | ||
| } | ||
|
|
||
| return ts.visitEachChild(node, visitNode, context); |
There was a problem hiding this comment.
If ngc always creates the variable declaration at the root level then only the source file's children should need to be analyzed. Walking the entire tree can be avoided. The regex test above can be avoided as well since top level nodes are typically fairly minimal and testing a large block of text will be much less efficient.
There was a problem hiding this comment.
That is a better approach, yes. I modified the code to only recurse into VariableStatement to find VariableDeclaration within, since the structure is VariableStatement -> VariableDeclarationList -> VariableDeclaration. PTAL
| nameLazyFiles?: boolean; | ||
| logger?: logging.Logger; | ||
| directTemplateLoading?: boolean; | ||
| discoverLazyRoutes?: boolean; |
There was a problem hiding this comment.
Should we warn (or probably error) in the transformer (or somewhere else) if the string form is found when this option is off?
Users may not know why their applications are not working.
2d7022f to
38fff6a
Compare
| ): ts.TransformerFactory<ts.SourceFile> { | ||
| return (context: ts.TransformationContext) => { | ||
| return (sourceFile: ts.SourceFile) => { | ||
| const warning = ` |
There was a problem hiding this comment.
Should this be a warning or an error, since it will cause a runtime error?
There was a problem hiding this comment.
It won't necessarily cause a runtime error. VE can still use both types of imports.
| export default async function () { | ||
| const projectName = 'ivy-lazy-loading'; | ||
| const argv = getGlobalVariable('argv'); | ||
| const ivyProject = argv['ivy']; |
There was a problem hiding this comment.
How are these run during the e2e-cli tests, Isn't the ivy arg used only in the cli snapshots?
Hence we would only be testing a subset of scenarios during the e2e's in PRs, to be more precise the VE tests.
We only have a limited tests for Ivy during E2E, and removing some might be risky. Unless we we have some e2e-cli-ivy job for PRs.
There was a problem hiding this comment.
Yes, Ivy tests are only run for snapshots now. I agree with you that we would love coverage. I think moving the ivy job to not use the snapshots, and to always run, is a good approach. We're starting to have more cde that interacts with Ivy so we should have confidence in PRs for it.
a4ac54e to
82f25f9
Compare
| destination: cli/new-production | ||
|
|
||
| e2e-cli-ng-snapshots: | ||
| e2e-cli-ivy: |
There was a problem hiding this comment.
nit: why switch the order of these? makes the delta harder to review
There was a problem hiding this comment.
To keep similar e2e jobs (e2e-cli and e2e-cli-ivy) together.
The old e2e-cli-ng-snapshots was after e2e-cli-ivy-snapshots because they shared the snapshot flag and only ran on some builds. Now e2e-cli-ivy-snapshots is instead e2e-cli-ivy and should instead be next to e2e-cli.
| nameLazyFiles?: boolean; | ||
| logger?: logging.Logger; | ||
| directTemplateLoading?: boolean; | ||
| discoverLazyRoutes?: boolean; |
There was a problem hiding this comment.
let's try to generally answer questions like this in the form of a comment in the code - no one later will find this thread
|
|
||
| loadChildren: () => import('IMPORT_STRING').then(m => m.EXPORT_NAME) | ||
|
|
||
| Please note that only IMPORT_STRING and EXPORT_NAME can be replaced in this format.`; |
There was a problem hiding this comment.
link to the guide again, if ppl get confused we'll be able to help them there
…iewEngine
This feature ONLY matches the format below:
```
loadChildren: () => import('IMPORT_STRING').then(m => m.EXPORT_NAME)
```
It will not match nor alter variations, for instance:
- not using arrow functions
- not using `m` as the module argument
- using `await` instead of `then`
- using a default export (angular/angular#11402)
The only parts that can change are the ones in caps: IMPORT_STRING and EXPORT_NAME.
82f25f9 to
c9b3071
Compare
|
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. |
This feature ONLY matches the format below:
It will not match nor alter variations, for instance:
mas the module argumentawaitinstead ofthenThe only parts that can change are the ones in caps: IMPORT_STRING and EXPORT_NAME.