Skip to content
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

I18nContext: Store React.Context with React version as a key #6930

Open
1 task done
codefactor opened this issue Feb 11, 2025 · 0 comments
Open
1 task done

I18nContext: Store React.Context with React version as a key #6930

codefactor opened this issue Feb 11, 2025 · 0 comments
Labels

Comments

@codefactor
Copy link

codefactor commented Feb 11, 2025

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

  1. Upgrade to webcomponents version 2.x
  2. 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: 2025-Q1
Development

No branches or pull requests

2 participants