microsoft
react-shared-context multiple instances cause problems with multiple dependency versions
Environment Information
- Package version(s): 9.0.0-beta.3, 9.0.0-beta.4
- Browser and OS versions: N/A
Problem
When an application ends up depending on multiple versions of the react-shared-context package, each version creates a different context instance. In this case, the theme from FluentProvider ended up undefined on one of the instances.
This issue points out a problem we need to solve with applications that end up with multiple versions of a shared fluent package that creates context. It could easily happen when an application takes a dependency on another package depending on fluent.
Solutions to consider
- It might be helpful to de-dupe the instances by putting the instance on the window so that multiple versions could check if the instance is already created.
- Different instances from different versions could be put onto the context with schema/version. satcheljs takes this approach.
- Ensuring that packages take fluent as a peer dependency with caret upgrade.
- Detecting multiple instances and warning developers to update the package.json resolutions to remove the duplicate packages.
Priorities and help requested:
This is very important to upgrade, especially while we ask partners to be trying to flight beta components that have breaking changes between versions.
@ling1726 @levithomason @layershifter - If you have thoughts on the versioning here please chime in. @MLoughry - LMK if I missed anything.
IMO versioning will not solve this problem. We should figure out a way to ensure that our singletons are interoperable even when there are multiple of them. I don't know any immediate ways we can do this, but we should do some research.
Ideally I would prefer this to be an extra layer in Fluent, so that we still rely on native React contexts, but provide utilties for more advanced users to allow intentional duplication of context singletons.
IMO versioning will not solve this problem. We should figure out a way to ensure that our singletons are interoperable even when there are multiple of them. I don't know any immediate ways we can do this, but we should do some research.
Basically what @ling1726 said, I'll bring this up on sync so we have someone to focus on solving the singletons issue from implementation stadpoint (DI / some kind of shim etc)
