-
Notifications
You must be signed in to change notification settings - Fork 598
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
feat: enable multiple fast-element instances in browser at once #5695
feat: enable multiple fast-element instances in browser at once #5695
Conversation
…ast-instances' into users/eisenbergeffect/multiple-fast-instances
Azure Static Web Apps: Your stage site is ready! Visit it here: https://purple-ocean-0b7ce3410-5695.centralus.azurestaticapps.net |
Azure Static Web Apps: Your stage site is ready! Visit it here: https://purple-ocean-0b7ce3410-5695.centralus.azurestaticapps.net |
Azure Static Web Apps: Your stage site is ready! Visit it here: https://purple-ocean-0b7ce3410-5695.centralus.azurestaticapps.net |
Azure Static Web Apps: Your stage site is ready! Visit it here: https://purple-ocean-0b7ce3410-5695.centralus.azurestaticapps.net |
Azure Static Web Apps: Your stage site is ready! Visit it here: https://purple-ocean-0b7ce3410-5695.centralus.azurestaticapps.net |
Azure Static Web Apps: Your stage site is ready! Visit it here: https://purple-ocean-0b7ce3410-5695.centralus.azurestaticapps.net |
1 similar comment
Azure Static Web Apps: Your stage site is ready! Visit it here: https://purple-ocean-0b7ce3410-5695.centralus.azurestaticapps.net |
Pull Request
📖 Description
Currently, you cannot have multiple copies of
@microsoft/fast-element
running on the same page at the same time. This has to do with certain core services and their private state which break each other. For example, an observable defined by one instance of FAST cannot be observed by another because the notifier cache is not shared between the two versions.This PR attempts to extract a set of core services that can be shared across all instances of
@microsoft/fast-element
running on the same page.This PR also tracks versions of FAST running at once.
🎫 Issues
No public issues. Various public and internal instances where this has been a challenge.
👩💻 Reviewer Notes
The basic approach is that fast-element now establishes a
FAST
global which can be accessed by all running instances. The global exposes a singleget
method to retrieve shared services by id. This means that whichever fast-element version is loaded first on the page gets to define the version of the service that all instances will use.Throughout the codebase, core services first attempt to retrieve the shared service. The API facilitates a "get or create" mechanism so that if the service is not available, the caller is able to provide an implementation.
The shared services are as follows:
The API report shows breaking API changes but that is only a change from several functions on objects to properties that are functions on object. The invocation pattern doesn't change for consumers, so this isn't really a breaking change.
📑 Test Plan
Testing this is a challenge. All of our existing tests pass, but those don't really exercise the scenario that this is a fix for. To test this, we'd need to have two separate bundles with two versions of fast-element, on the same page at once. We don't have infrastructure setup for doing that sort of test in this repo.
To address this, I've created a manual test: FAST Multi Instance Test.zip.
The attached example loads two copies of fast-element simultaneously. Two web components are defined, one with each version of the library. All code is vanilla JS, defined in script tags of type module.
Console Output
The console shows that the observable service used by both fast-element copies is the same instance and that there are two versions of fast-element loaded.
Additional Checks
✅ Checklist
General
$ yarn change
⏭ Next Steps
This PR only attempts to handle scenarios where there are multiple copies of fast-element present. There may be additional issues with multiple copies of
fast-foundation
. That would need to be explored separately. Any fixes there would be dependent on the version of fast-element with this set of changes.Furthermore, there are some things that are just not fixable, such as cross version
instanceof
checks or libraries that attempt to callcustomElements.define
with the same tag name. No attempt will be made to hack around those platform restrictions.These changes will need to be ported to FASTElement 2.0 as well. It is unclear at this time wether we will be able to support both FE1 and FE2 on the same page with this mechanism. If we can keep these core services compatible, we will. But we don't know if that's possible just yet.
As part of FE 2.0 we're hoping to put a better error/warn message system in place. Our infrastructure doesn't make that easy right now so we're delaying the warn about multiple versions until then.