feat(youtube-player): add config option to automatically load the YouTube API

[crisbeto]

Adds a new injection token that allows the YouTubePlayer to automatically load the API, instead of depending on it to be loaded by the consumer.

Fixes #17037.

[crisbeto]

@jelbourn I would appreciate your feedback on a couple of things that I was considering when implementing it:

1. How the config should be provided: through an injection token like here or through something like YouTubePlayerModule.withConfig({ loadApi: true }). I went with the former, because it's clearer what is going on, but I can see an argument for the latter, because the API is a bit cleaner and I expect that the most common use case would be to let the component load the API automatically. I wouldn't mind changing it to use the second approach.
2. Whether loadApi should be turned on by default. I decided against it, because it does add an external script to people's apps and I figured that's something we'd want them to opt into, but it does make it slightly harder to consume.

[jelbourn]

I'm still quite leery of adding an API that loads the API for you. My rationale is along the lines of:

• This isn't something we do for any other dependency.
• I generally think developers should be aware of how they're loading deps into their application, and I'm not a fan of having a black-box API that obscures that.
• Having an API for loading the dependency implies that there's a "correct" way to do it, when it depends somewhat on what the app wants to do.
• It's easier for apps to end up in a state with multiple versions of the dependency loaded

I'll also comment this on the issue

[crisbeto]

I think that your points are valid, but here's why I decided to do it:

1. Getting the loading "right" can be tricky, because you'd have to coordinate it between inserting the script with the DOM API and keeping the component from initializing through something like ngIf. It's much easier to do it once on our end.
2. If you want to load the API yourself only when the component is used, you'll either have repeat some logic or write a wrapper component which means that you'd have to forward all the inputs.
3. The only way to consume the API is through a script pointing to the Google CDN. As far as I'm aware, there's no option to host it yourself, unless you copy the script somewhere, but then it can break on you at any time.

Regarding your points:

This isn't something we do for any other dependency.

I was planning to do something similar for the Google Maps API, if we managed to agree how this one would be handled, since it's set up in the exact same way.

I generally think developers should be aware of how they're loading deps into their application, and I'm not a fan of having a black-box API that obscures that.

I think that's fair for something like Angular or jQuery where there are different versions and ways to load the code. In the YouTube case, this is the only way of doing it since our component is tightly coupled to the iframe API.

Having an API for loading the dependency implies that there's a "correct" way to do it, when it depends somewhat on what the app wants to do.

As I mentioned above, in this particular case there is only one way of loading the API. The only decision is between loading it up-front or doing so lazily and I'd argue that doing it lazily is preferable.

It's easier for apps to end up in a state with multiple versions of the dependency loaded

As far as I'm aware, there is only one possible version. There's a risk of including the script tag multiple times, but our code should account for that.

[crisbeto]

Closing in favor of #28171.

[angular-automatic-lock-bot]

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.}