I’d like understand the customer’s experience during the transition from Feature X running as a Connect-on-Forge module to Feature X running as a native Forge module.
The new Forge-only module will require new permission scopes, so that will require approval from site admins. What state will our app be in between the release of the new module and approval by an admin? Will we need to support the old connect-based version of Feature X alongside the new Forge-only version of Feature X during the transition? Can our app know whether the admin has approved the update and thereby present one or other version of Feature X to the user?
Good question. If removing the connectModule and adding the module and scopes in your manifest.ymlis enough to transition between features, then presentation of the appropriate feature will be handled by Forge - the connectModule will keep being presented on sites that haven’t upgraded, and the module on sites that have - the contents of the manifest are also versioned.
Will that do it for you or will your backend willl need to be able to make the distinction as well?
That’s perfect, Jimi. Our backend will support both front-end modules concurrently, since we’re developing the Forge Remote endpoints as separate pieces of code.
The versioning of the manifest also means that the new module won’t be presented to the users until the installationId will have been captured and stored in our database.
