Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test(ivy): remove ngComponentOutlet example with a lazy-loaded NgModule #29094

Conversation

pkozlowski-opensource
Copy link
Member

@pkozlowski-opensource pkozlowski-opensource commented Mar 4, 2019

This PR removes one of the existing examples and the associated e2e test. This might sound like a terrible thing to do (why would one remove an example from documentation???) but I will argue that this example does more harm than good.

There are multiple levels of problems with the code being demonstrated and the test setup, let me explain it step by step:

  • the primary problem is in the API of ngComponentOutlet - this directive takes component Type and NgModuleFactory as @Input()s. Normally the Type should be enough but in view engine it is not enough for lazy loaded modules. So NgModuleFactory was introduced to support components from lazy-loaded modules but this is wrong API - componentFactoryResolver should have been used instead as it would cover both regular and lazy-loaded modules;
  • Type was used instead of componentFactoryResolver since dealing with componentFactoryResolver is less ergonomic as compared to simply using Type. But this limitation will go away in ivy so introducing componentFactoryResolver into ngComponentOutlet at this point would just confuse everyone;
  • so we are stuck with NgModuleFactory before ivy is default but getting an instance of NgModuleFactory in practice is super-difficult for an end-user - one either need to lazy-load it or use a Compiler (as in the example being deleted). I don't think that we want to teach people usage of Compiler for lazy loaded modules so this is why I'm claiming that the current example does more harm than good (teaches Compiler instead of lazy loading).

With ivy all those workflows (lazy loading, dynamic component instantiation) will get dramatically simpler so there is no great value in building examples on broken APIs and overly complex workflows.

As such I'm proposing the following:

  • pre-ivy - re-move the confusing example (this is done in this PR);
  • post-ivy: depreciate ngComponentOutletNgModuleFactory !: NgModuleFactory<any>; input

@pkozlowski-opensource pkozlowski-opensource added action: review The PR is still awaiting reviews from at least one requested reviewer target: major This PR is targeted for the next major release comp: ivy labels Mar 4, 2019
@ngbot ngbot bot added this to the needsTriage milestone Mar 4, 2019
@pkozlowski-opensource pkozlowski-opensource marked this pull request as ready for review March 4, 2019 14:42
@alfaproject
Copy link
Contributor

You can probably deprecate in version 8 (now?), and then it will get removed in like version 10, right?

Copy link
Contributor

@kara kara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (global approval)

@kara kara added action: merge The PR is ready for merge by the caretaker merge: caretaker note Alert the caretaker performing the merge to check the PR for an out of normal action needed or note and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Mar 4, 2019
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes merge: caretaker note Alert the caretaker performing the merge to check the PR for an out of normal action needed or note target: major This PR is targeted for the next major release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants