You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In version 1.x the I18nProvider is storing a global context on the window and sharing across multiple React cores. This triggers unexpected problems when one bundle has a different copy of React. In particular, if one core has React 18 and another core has React 19 the contexts are not backwards compatible.
Store the Context in a way that it would not try to share the React.Context if the major version of the React core is different. The version of React can be read from React.version and you could use that as a key on the global object you're using here:
For efficiency reasons, if you want to have newer copies of webcomponents-react benefit from the globals that were already stored by older copies of webcomponents-react stored on the window - you could read the current I18nContext and ducktype it for the current React version and utilize it only when it duck types correctly.
However, if you do this - you'll probably NOT want to store the old I18nContext in the global anymore so that way the newer ui5-webcomponents will NOT be sharing it's I18nContext with older versions so that way in real scenarios the one package that has upgraded to React 19 could also upgrade ui5-webcomponents-react version and deploy their changes without impacting the dozens of widgets that are already deployed with React 18.
I realize that version 1.x of ui5-webcomponents-react might be deprecated in favor of version 2.x - but teams need time to upgrade ui5-webcomponents to version 2.x - and they may not be able to do one of the alternatives. This enhancement seems possible, backwards compatible, and fairly easy to do and would allow teams to be able to simply upgrade ui5-webcomponents-react to a newer v1.x version rather than require them to upgrade/downgrade React in the short term fix before they can migrate to version 2.x of ui5-webcomponents.
Alternative Solution:
Refactor the I18nContext to no longer store React-specific objects onto the window at all and utilize objects that are not tied to the React version to share state.
Describe alternatives you've considered
Upgrade to webcomponents version 2.x
Ensure that all webcomponents-react cores share the same major version of React
Additional Context
SuccessFactors organization offers widgets that can be consumed by partner web sites. Our widgets utilize bundled ui5-webcomponents plus react. In production our widgets use version 1.x of webcomponents and 18.x of react. On some consumer partner site, the consumer had a copy of ui5-webcomponents-react at version 1.x with react 19.x -- on every other page the widget runs fine, but on this site the React-dom v19.x React.Context tries to run with React-dom at version 18.x and the React Fiber gets confused thinking that the I18nContext
Organization
SuccessFactors
Declaration
I’m not disclosing any internal or sensitive information.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
In version 1.x the
I18nProvider
is storing a global context on the window and sharing across multiple React cores. This triggers unexpected problems when one bundle has a different copy of React. In particular, if one core has React 18 and another core has React 19 the contexts are not backwards compatible.See:
https://github.com/SAP/ui5-webcomponents-react/blob/v1.29.x/packages/base/src/context/I18nContext.ts
Describe the solution you'd like
Store the Context in a way that it would not try to share the React.Context if the major version of the React core is different. The version of React can be read from
React.version
and you could use that as a key on the global object you're using here:https://github.com/SAP/ui5-webcomponents-react/blob/v1.29.x/packages/base/src/context/I18nContext.ts
For efficiency reasons, if you want to have newer copies of webcomponents-react benefit from the globals that were already stored by older copies of webcomponents-react stored on the window - you could read the current I18nContext and ducktype it for the current React version and utilize it only when it duck types correctly.
However, if you do this - you'll probably NOT want to store the old I18nContext in the global anymore so that way the newer ui5-webcomponents will NOT be sharing it's I18nContext with older versions so that way in real scenarios the one package that has upgraded to React 19 could also upgrade ui5-webcomponents-react version and deploy their changes without impacting the dozens of widgets that are already deployed with React 18.
I realize that version 1.x of ui5-webcomponents-react might be deprecated in favor of version 2.x - but teams need time to upgrade ui5-webcomponents to version 2.x - and they may not be able to do one of the alternatives. This enhancement seems possible, backwards compatible, and fairly easy to do and would allow teams to be able to simply upgrade ui5-webcomponents-react to a newer v1.x version rather than require them to upgrade/downgrade React in the short term fix before they can migrate to version 2.x of ui5-webcomponents.
Alternative Solution:
Refactor the I18nContext to no longer store React-specific objects onto the window at all and utilize objects that are not tied to the React version to share state.
Describe alternatives you've considered
Additional Context
SuccessFactors organization offers widgets that can be consumed by partner web sites. Our widgets utilize bundled ui5-webcomponents plus react. In production our widgets use version 1.x of webcomponents and 18.x of react. On some consumer partner site, the consumer had a copy of ui5-webcomponents-react at version 1.x with react 19.x -- on every other page the widget runs fine, but on this site the React-dom v19.x React.Context tries to run with React-dom at version 18.x and the React Fiber gets confused thinking that the I18nContext
Organization
SuccessFactors
Declaration
The text was updated successfully, but these errors were encountered: