Hi, I was wondering about good patterns concerning the react context.
Let's get a public library, for example react-intl
that exposes a Provider (IntlProvider).
Let's create a library barLib
that uses react-intl
to manage translations internally and that also exposes a Provider
.
Now let's imagine I create a web app and use both barLib
and react-intl
.
I don't expect the barLib
to ever override my react-intl context, because i'm not aware it uses internally the react-intl
lib.
But the barLib
can accidentally override the react-intl context => https://codesandbox.io/s/embedded-contexts-test-z8e7b
This kinda breaks the isolation of libs IMO.
I see several solutions :
- Don't use an other lib context in the
barLib
(pretty extreme) - Check that there is not already an intl context in the
barLib
, if so merge the context values ?
I'm not convinced with either solutions, what do you guys think about it ?
UPDATE :
IMO the right way is to NEVER implement yourself a provider from a third-party library, you should just document your library so that users know they should wrap your components with the needed provider.
Exemple : If you want to use react-intl
, just use it and tell people that your component must be wrapped into a react intl provider.
Top comments (0)