emotion 9 --> emotion 10 #3321

gwyneplaine · 2019-01-04T08:46:43Z

Refactor our usage of create-emotion as of v2.2.0 to emotion 10, and reverting the addition of the custom emotion instance passed into each component.

Please see the following PR for context on the create-emotion change: #3260
This is also an indirect response to the following issue #3317 caused by the above PR 😄

There's a few valid reasons for the upgrade:

Zero configuration SSR is very appealing, especially for users who are using css-in-js solutions other than emotion.
nonce support for CSP is trivial, and doesn't involve creating a custom emotion instance.
Users on latest version of emotion, don't need to worry about pulling in multiple versions of emotion because of react-select.
Not passing in a custom emotion instance to every component that needs styling is actually kind of ok, it means the api for our components aren't bound to a specific css-in-js solution, making future changes to our styling opinions less obtrusive.

Possible arguments against emotion 10:

Support for react 15 users who aren't able to use the new context api
This could be a breaking change for users using the components api ** (see rebuttal below)

** this is only true for users who are completely rewriting components, and doing their own style composition. Users on emotion 10 who are doing this should be familiar with this syntax already, users who are using any other css-in-js solution should have the necessary tools to create functioning custom components without having to use emotion.

Things I want to validate before this PR goes through:

That support for react 15 is a non-issue @JedWatson
That we're leveraging the correct patterns in our use of emotion 10 @mitchellhamilton
The assertion that while this is a non-trivial change to our internal css-in-js implementation, it is ultimately a non-breaking change for users of the custom components api.

gwyneplaine · 2019-01-06T23:34:31Z

package.json

@@ -48,7 +50,7 @@
    "css-loader": "^0.28.7",
    "cypress": "^1.4.1",
    "dotenv": "^5.0.1",
-    "enzyme": "^3.3.0",


upgrade enzyme so it plays well with emotion 10 and new context api

gwyneplaine · 2019-01-06T23:34:55Z

src/Select.js

 import memoizeOne from 'memoize-one';
-import createEmotion, { type Emotion } from 'create-emotion';


removed createEmotion in favor of emotion 10s CacheProvider and createCache for adding nonce support.

gwyneplaine · 2019-01-06T23:35:56Z

src/Select.js

@@ -1703,7 +1696,7 @@ export default class Select extends Component<Props, State> {
              onTopArrive={onMenuScrollToTop}
              onBottomArrive={onMenuScrollToBottom}
            >
-              <ScrollBlock emotion={this.emotion} isEnabled={menuShouldBlockScroll}>


we don't want to be doing this anymore, it locks us into emotion as an intrinsic part of our components API, while this is true of our own implementations, this should ultimately not be true for power users.

gwyneplaine · 2019-01-06T23:37:48Z

src/components/Control.js

+      {({ css }) => (
+        <div
+          ref={innerRef}
+          className={cx(css(getStyles('control', props)), {


Here we're using the ClassNames fn from emotion 10 to access the css method so we can pass the processed style objects from css(getStyles()) to our custom cx implementation.

@mitchellhamilton I just wanted to sanity check the fact that we're using a custom cx implementation her instead of the one provided to us by ClassNames is ok.

Using your own cx function is totally fine, it just means that emotion styles won't be merged together which in this case, I don't believe it matters. I'm not really sure about this whole approach though, ClassNames is intended to be a workaround when a component doesn't accept a className prop, I'd recommend an approach like this:

diff --git a/src/components/Control.js b/src/components/Control.js index a964547..c38a9ad 100644 --- a/src/components/Control.js +++ b/src/components/Control.js @@ -1,6 +1,7 @@ // @flow -import React, { type Node, type ElementRef } from 'react'; -import { ClassNames } from '@emotion/core'; +import { type Node, type ElementRef } from 'react'; +/** @jsx jsx */ +import { jsx } from '@emotion/core'; import type { CommonProps, PropsWithStyles } from '../types'; @@ -56,22 +57,19 @@ export const css = ({ const Control = (props: ControlProps) => { const { children, cx, getStyles, className, isDisabled, isFocused, innerRef, innerProps, menuIsOpen } = props; return ( - <ClassNames> - {({ css }) => ( - <div - ref={innerRef} - className={cx(css(getStyles('control', props)), { - 'control': true, - 'control--is-disabled': isDisabled, - 'control--is-focused': isFocused, - 'control--menu-is-open': menuIsOpen - }, className)} - {...innerProps} - > - {children} - </div> - )} - </ClassNames> + <div + ref={innerRef} + css={getStyles('control', props)} + className={cx({ + 'control': true, + 'control--is-disabled': isDisabled, + 'control--is-focused': isFocused, + 'control--menu-is-open': menuIsOpen + }, className)} + {...innerProps} + > + {children} + </div> ); }; diff --git a/src/utils.js b/src/utils.js index 0787bfd..d37f037 100644 --- a/src/utils.js +++ b/src/utils.js @@ -41,11 +41,10 @@ function applyPrefixToName(prefix, name) { export function classNames( prefix?: string | null, - cssKey?: string | null, state?: ClassNamesState, className?: string, ) { - const arr = [cssKey, className]; + const arr = [className]; if (state && prefix) { for (let key in state) { if (state.hasOwnProperty(key) && state[key]) {

gwyneplaine · 2019-01-06T23:39:55Z

src/components/indicators.js

+        viewBox="0 0 20 20"
+        aria-hidden="true"
+        focusable="false"
+        className={css({


@mitchellhamilton We technically don't need to be using ClassNames here to access the css method, since we aren't generating a custom className using our own cx implementation, however I noticed that using the css prop with the jsx pragma generated a style tag without a nonce attribute. Not sure why this is the case, but using the ClassNames renderProp to circumnavigate this for now

That's very strange, gonna look into it.

Updating to latest of babel-plugin-emotion resolves this issue

gwyneplaine · 2019-01-06T23:42:24Z

src/components/indicators.js

-    })}
-  />
+type DotProps = { color: string, delay: number, offset: boolean };
+const LoadingDot = ({ color, delay, offset }: DotProps) => (


@mitchellhamilton same as with the svg example above, technically not necessary to use here, but noticed that nonces were not being added, and the keyframes`` call above was not working.

jossmac

LGTM

gwyneplaine · 2019-01-10T00:35:22Z

@JedWatson after talking to @jossmac we agreed that this is a breaking change, and should be a 3.0.0.

williamtstanley · 2019-01-18T20:19:22Z

With this update how would I style custom Options? I used to get emotion as a prop but nolonger... I also don't seem to be getting css as a replacement any longer...

Sorry I just realized that css can come from my import of {css} from emotion...

Faradey27 · 2019-02-01T22:19:16Z

@gwyneplaine are we plan to merge this?

gwyneplaine · 2019-02-03T23:58:44Z

@Faradey27 plan is to merge this as a 3.x, we're doing a bit of clean up to release another 2.x.x before this happens, thanks for the patience

ematipico · 2019-03-15T14:44:21Z

This is critically needed.
We can't afford to install install emotion only to support SSR. Thanks! Is there any rough idea on when v3 will be released?

gwyneplaine · 2019-03-22T02:55:54Z

hey @ematipico, thanks for raising interest in this body of work.
I've been a little swamped over the past few weeks, but am intending to ship 3.0.0 with emotion 10 towards the end of the month. Thanks for your patience :)

leerob · 2019-04-16T17:20:06Z

Would love to see this get released! We've had to do a bunch of workarounds to get react-select working with Next.js and this would prevent that.

jossmac · 2019-04-16T21:19:07Z

@gwyneplaine give me a yell if you need a hand with anything. Happy to pair on this.

piesrtasty · 2019-04-26T02:45:45Z

Any ETA on when this will be merged in?

…omponent

senorgeno · 2019-05-22T01:42:15Z

@leerob I am using this with Gatsby and having issues after SSR. Any advice on what workarounds you used to get it to work with Next.js? Looking forward to v3.0.0 👍

vaunus · 2019-05-22T06:25:46Z

@senorgeno I am just forcing client-side only rendering for now until this is released by wrapping the select with <NoSSR>. I'm importing NoSSR from MaterialUI as I am using that in my project, but I imagine any of the other implementations of it would work as well.

senorgeno · 2019-05-23T01:45:08Z

Thanks @vaunus <NoSSR> worked for me in the mean time

gwyneplaine mentioned this pull request Jan 4, 2019

SSR 2.2.0 - createEmotion #3317

Closed

gwyneplaine force-pushed the emotion-10 branch from 18de288 to 38a5147 Compare January 6, 2019 23:09

gwyneplaine requested review from JedWatson and jossmac January 6, 2019 23:33

gwyneplaine commented Jan 6, 2019

View reviewed changes

jossmac approved these changes Jan 6, 2019

View reviewed changes

gwyneplaine changed the title ~~initial emotion 9 --> emotion 10~~ emotion 9 --> emotion 10 Jan 7, 2019

gwyneplaine force-pushed the emotion-10 branch from eba74b2 to 6304b9b Compare January 9, 2019 04:15

This was referenced Jan 14, 2019

Revert 3260 #3346

Merged

[V2] Request/Bug: Needs CSP Considerations #2917

Open

gwyneplaine force-pushed the emotion-10 branch from 6304b9b to 6f1c946 Compare January 25, 2019 04:38

gwyneplaine added the 3.x release label Feb 11, 2019

gwyneplaine mentioned this pull request Mar 22, 2019

[v2] Support for Emotion 10 #3276

Closed

gwyneplaine added 3 commits April 26, 2019 14:14

initial emotion 9 --> emotion 10

00e7680

fix tests

7449e86

goodbye create-emotion

f9e538f

gwyneplaine added 5 commits April 26, 2019 14:19

update babel-plugin-emotion and docs

8b8c8e4

refactor components to use jsx pragma method rather than ClassNames c…

a3e4ba3

…omponent

update snapshots

263db7a

add NonceProvider and remove nonce prop from base Select

c9364b1

fix advanced examples to use emotion 10

0913682

gwyneplaine force-pushed the emotion-10 branch from 6f1c946 to 0913682 Compare April 26, 2019 04:26

fix flow type for A11yText

204219b

gwyneplaine changed the base branch from master to v3.0.0 April 26, 2019 04:54

gwyneplaine merged commit 8ac29a9 into v3.0.0 Apr 26, 2019

gwyneplaine mentioned this pull request Apr 29, 2019

3.x TODO #3529

Closed

10 tasks

gwyneplaine mentioned this pull request May 23, 2019

V3.0.0 #3574

Merged

dcousens deleted the emotion-10 branch October 19, 2022 05:30

		import memoizeOne from 'memoize-one';
		import createEmotion, { type Emotion } from 'create-emotion';

emotion 9 --> emotion 10 #3321

emotion 9 --> emotion 10 #3321

Uh oh!

Conversation

gwyneplaine commented Jan 4, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

There's a few valid reasons for the upgrade:

Possible arguments against emotion 10:

Things I want to validate before this PR goes through:

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jossmac left a comment

Choose a reason for hiding this comment

Uh oh!

gwyneplaine commented Jan 10, 2019

Uh oh!

williamtstanley commented Jan 18, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Faradey27 commented Feb 1, 2019

Uh oh!

gwyneplaine commented Feb 3, 2019

Uh oh!

ematipico commented Mar 15, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gwyneplaine commented Mar 22, 2019

Uh oh!

leerob commented Apr 16, 2019

Uh oh!

jossmac commented Apr 16, 2019

Uh oh!

piesrtasty commented Apr 26, 2019

Uh oh!

senorgeno commented May 22, 2019

Uh oh!

vaunus commented May 22, 2019

Uh oh!

senorgeno commented May 23, 2019

Uh oh!

Uh oh!

gwyneplaine commented Jan 4, 2019 •

edited

Loading

williamtstanley commented Jan 18, 2019 •

edited

Loading

ematipico commented Mar 15, 2019 •

edited

Loading