Fix plugin loader for function definitions in window

[Maxr1998]

This reverts commit 2dede41 and fixes supporting functions as well as classes as plugin definitions in window.

The previous change breaks plugin loading on Android, as plugin definitions with a function return a Promise to the class (async function), which cannot be instantiated. The Promise needs to be awaited on first; and the instantiation requires the default dependencies as constructor arguments.

[nielsvanvelzen]

This will fail if pluginInstance is a class because constructing a class needs the new keyword.

See #2157 and #2159

[Maxr1998]

But if it is a class, it'll still break because it's missing the arguments/it's calling new twice. We have to fix this differently then..

[nielsvanvelzen]

Something like this might work, did not test it:
if (typeof pluginInstance === 'function' && !pluginInstance.constructor) {

[Maxr1998]

Yes, that could work. I'll try it later and if it does, I'll add it to this PR.

[Maxr1998]

Looks like it doesn't, since functions also have the constructor attribute.

[Maxr1998]

I just pushed a "fix", the code looks a bit Spaghetti, but should be working. Gotta do some additional testing though.

[Maxr1998]

Tested on production with the Android app, and it works just fine 🎉

[thornbill]

I'm not a fan of the spaghetti this adds. Maybe we should just straight revert and not support classes directly? Is it bad if we just say for classes you must return them from a function? window.MyPlugin = () => MyPluginClass

It would be nice if we had a well defined spec for these plugins and what is supported.

[Maxr1998]

As long as there's a documented spec, I'm happy with both options. We just need to decide and document it somewhere.

[nielsvanvelzen]

Maybe we should just straight revert and not support classes directly?

jellyfin-android does use functions because classes didn't work when I implemented it so I guess we can remove it yes.

[Maxr1998]

I reverted my spagehtti-ish workaround, as we discussed internally to not support the classes directly in window. Instead, that should be documented and this PR could be merged now. However, I still want to use some changes from my earlier commit (4b7ccc4) to refactor the current code a bit and make it more readable.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication