[alx-andru]

Checklist

• Issue number for this PR: 5.3.0 not working in IE 11 due to proxy object #2296
• Docs included?: not yet
• Test units included?: not yet
• In a clean directory, yarn install, yarn test run successfully? yes

Description

The new Proxy implementation is not natively compatible with IE11. The recommended polyfill proxy-polyfill has limitations and requires an object to have all properties assigned at creation time of the new proxy object.

The AngularFireAuth class inherits from the Auth interface (part of the firebase SDK) and only implements angular specific augmentation to the existing interface.

This PR re-declares the existing interface from the imported auth.Auth interface and assignes each property with null. This guarantees that properties are known to the proxy and can be invoked using the proxy-polyfill with IE11.

Further, es5 does not support Array.prototoype.includes. I wasn't sure how to workaround this, as the specific use-case is not complex, an indexOf was being used.

Code sample

N/A

[alx-andru]

I would appreciate feedback on the proposed solution as I'd be happy to extend the PR to the other modules to provide a more complete solution as well as documentation on how to use AngularFire with IE11.

[jamesdaniels]

Hmmm, I'm wondering if there's any way we could inject these null properties at built-time. That way it's a bit more automated & less of a maintenance burden.

[alx-andru]

I'm not too familiar with the build process yet but I'd be happy to explore some options. Are there any approaches you'd be thinking of right away?

Would it be also an option to use the initial approach in order to allow developers to update the package and maintain IE11 support with the latest releases until a more efficient solution is identified?

[alx-andru]

Just following up, I'd be able to go ahead and complete the interface re-declarations as a current approach. I wasn't able to find a feasible way to provide a more automated approach. If there are some ideas I'd be happy give them a try and implement accordingly.

[alx-andru]

Based on the comments in #2296 it doesn't seem to be an approach to follow further as the implications for maintenance would exceed the benefits.

[jamesdaniels]

@alx-andru feel free to toss your indexOf change in another PR, that doesn't seem like a maintenance burden :P I'm going to keep thinking on this, maybe I'll come up with something that isn't too hard... though with a new modular version of the JS SDK on the way I'll be rethinking many of the assumptions with the current API in the coming weeks.