Upgrades Emotion to v11

[majgaard]

Hi 👋

With Emotion v11 being released and many other packages (including Chakra-UI) upgrading their dependencies, react-select should follow suit.

The predominant reason for this is that having mismatched versions of Emotion can cause lots of issues. See this issue for one of many examples.

[changeset-bot]

🦋 Changeset detected

Latest commit: e5151bb

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@react-select/docs	Major
react-select	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit e5151bb:

Sandbox	Source
react-codesandboxer-example	Configuration

[giovannigiordano]

@belgattitude @majgaard any update on this?

[majgaard]

This is largely good-to-go from my end. There are 2 Flow-typing issues. One can be fixed somewhat easily, but I'm not sure how the maintainers would prefer to fix it. The other issue is because Flow can't find the Stylis module. I'm not particularly familiar with Flow and I have been unable to fix the issue.

[sneridagh]

@majgaard @JedWatson This is starting to be painful, any update? Sorry, but I can't do Flow, so I'm not able to jump in.

[Methuselah96]

@sneridagh We're planning to include this in 4.0 (which we're hoping to release soon). I'm looking into the Flow errors now.

[with-heart]

Hi @Methuselah96, Chakra UI maintainer here. Glad to hear this is scheduled for v4 🎉 Let me know if there's anything I can do to assist with this!

[JedWatson]

Looks good, two small changes and we can get this merged

[majgaard]

We should be all good! 🎉

[kpunith8]

@majgaard looks like @emotion/jest is not updated to the latest version, it is still pointing to jest-emotion, and is used here, https://github.com/JedWatson/react-select/blob/master/packages/react-select/src/__tests__/Select.test.js#L15 I found this while I was forking and updating to emotion-11 using the codemod rule "@emotion/pkg-renaming": "error"

Not sure this is a blocker for this PR to go.

[majgaard]

@kpunith8 Thanks for spotting that! b573dca should take care of that. Also had to regenerate snapshots because of the updated serializer.

[jdelStrother]

Can anyone suggest what a good cacheKey for NonceProvider is? I'm not familiar with emotion, so I'm not sure whether it's supposed to be a different cacheKey for each component, or each nonce, or each page ..?

[Methuselah96]

I believe it should be a unique cacheKey per NonceProvider (i.e., a unique cacheKey per Emotion cache since each NonceProvider has its own cache).

[ebonow]

I added a note to #3006 to add examples to the documentation for NonceProvider. I struggled finding adequate information on this trying to search through Emotions's documentation.

[jdelStrother]

If it’s per-NonceProvider, wouldn’t it make more sense for NonceProvider to generate its own key rather than making other developers figure this out?

…

On 30 Jan 2021, at 18:08, Eric Bonow ***@***.***> wrote:  I added a note to #3006 to add examples to the documentation for NonceProvider. I struggled finding adequate information on this trying to search through Emotions's documentation. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[Methuselah96]

@Andarist @mitchellhamilton Can you provide some guidance here? We provide a NonceProvider component that can be used to wrap the Select component in order to add nonce support. What should be the scope of the key being passed into createEmotionCache (i.e., per app, per component, per component instance)?

[Andarist]

The scope of the key should be, well, per the cache instance and ideally, no 2 caches should use the same key. If you share a single cache through different CacheProviders then this should be OK.

[jdelStrother]

The scope of the key should be, well, per the cache instance

Forgive me, I think I must be missing something important in how emotion works or how it implements caching. Doesn't that mean that emotion ought to be responsible for scoping its own cache keys? What would be the benefit in a client supplying the same cache key to different cache instances?

[Andarist]

What would be the benefit in a client supplying the same cache key to different cache instances

I'm saying that this should not be done - each new cache should have a new key. Caches integrate with the DOM and it's a shared, global resource - hence the need for keys.

[Methuselah96]

I'm saying that this should not be done - each new cache should have a new key.

If this is the case then would it be possible for the Emotion cache to generate its own key (one per instance)?

[Andarist]

Mainly because of SSR

[jdelStrother]

Say if I have two <Select> components on the page, each wrapped in their own . The two NonceProviders share the same nonce. Can both of them use the same cacheKey? If the two select components have different style props, does that change the answer?

Just using a static cacheKey seems like it works fine, but I'm not really sure what I'm breaking by doing so.

[ebonow]

Say if I have two <Select> components on the page, each wrapped in their own . The two NonceProviders share the same nonce. Can both of them use the same cacheKey? If the two select components have different style props, does that change the answer?

Just using a static cacheKey seems like it works fine, but I'm not really sure what I'm breaking by doing so.

My suspicion would be that you may run into issues if you try to apply two different styles to the same component if the using the same cacheKey.

For instance if you want to set the border red in one of your Selects,

const styles = { control: css => ({ ...css, borderColor: 'red' }) }

It could be merging all of the styles together and likely would result in all Selects have a red border. I could be wrong though, and would be interested in seeing the impact or having better familiarity with the impact.

[Andarist]

Say if I have two Select components on the page, each wrapped in their own . The two NonceProviders share the same nonce. Can both of them use the same cacheKey?

No - they couldn't use the same cacheKey but you could share the very same cache instance for both, resulting in the same cacheKey being used without any problems. The difference is that you suggest using 2 caches while I propose using a single cache. You just can't create caches per NonceProvider in this scenario - you can still create them lazily there but you'd have to use memoization to actually reuse the same cache for the second NonceProvider.

It could be merging all of the styles together and likely would result in all Selects have a red border. I could be wrong though, and would be interested in seeing the impact or having better familiarity with the impact.

I'm not aware of how React Select works but I would suspect that this is not true - styles should be still scoped per component and Emotion caches don't have much to do with that. They are mainly responsible for injecting a given ruleset once to the CSSOM (and have some global-like options).

[jdelStrother]

Thanks @Andarist, that clears things up.

For the react-select people - I don't think NonceProvider is ideal for our use case, where we have a multi-root react app (boring old static html pages, with multiple react components mounted at different locations on the page). I ended up re-implementing our own version of NonceProvider to share a single cache with a fixed key. A tiny snippet in case it helps anyone else:

import { CacheProvider } from "@emotion/react";
import createCache from "@emotion/cache";
import memoizeOne from "memoize-one";
import cspNonce from "lib/csp_nonce";

const sharedCache = memoizeOne((nonce) =>
  createCache({ nonce, key: "ab-react-select" })
);
function withNonceProvider<Config extends {}>(
  Component: React.ComponentType<Config>
): React.ComponentType<Config> {
  return (props: any) => (
    <CacheProvider value={sharedCache(cspNonce())}>
      <Component {...props} />
    </CacheProvider>
  );
}