Emotion 10 is mostly ready now except for docs, the final package names and potentially waiting for the new stylis rewrite.
Currently all the new stuff is on the @emotion npm scope though I don't think that's necessarily how it should be for the final release since it would create lots of churn.
My current thinking is
emotion stays like it is right now with css that returns a class name and etc. (my only problem with that is it could cause people to install it instead of @emotion/core which could likely be what they want)react-emotion has two bridge versions published, one that only exports styled and one that exports styled and emotion's exports (I'm not totally sure about this)emotion-theming has a peerDep on @emotion/core and exports withTheme and ThemeProvider like it does nowbabel-plugin-emotion is the babel plugin@emotion/core, @emotion/styled and etc. stay on the scope like how they are now.I'm not totally sure about all of this so I'd love to hear people's thoughts on this!!!
Could you explain why react-emotion would be published with 2 flavours?
I agree that everything that was already public should preserve their original name, other things can stay within @emotion scope.
Also - I'm super excited about this!

Because most users of react + emotion shouldn't be using the emotion package in v10 (though they totally can if they need too and probably should while they're migrating).
The idea that I was saying is that people should switch to @emotion/styled (again, I'm not totally sure about everything, especially this bit) but they can use versions of react-emotion for dependencies that haven't updated yet and there should be another version that only exports styled so that people can avoid pulling in emotion if the dependency that hasn't updated doesn't use any of the emotion exports.
For example, rebass/emotion uses react-emotion but it only uses styled so people could avoid pulling in emotion.
Oh, I didn't know that release of emotion 10 is this soon.... I need to work hard for typing :(
@mitchellhamilton would it be possible to re-export consume function i @emotion/core from /core/context.js ? I'm working on custom theming ui react lib based on emotion 10 and having access to context (and theme prop) inside my component logic would be really nice, so I could use it in the same way as new React.Consumer context API.
@tadeuszwojcik Do you only need the theme or do you also need the rest of context?
Could you talk more about your use case and why you need context inside of your component logic?
@mitchellhamilton thanks for quick reply.
I actually need only theme provided by the provider. I'm trying to implement something like this:
Given theme:
js
const theme = {
color: {
primary: 'blue',
secondary: 'red'
},
space: {
xSmall: 10,
medium: 20
}
};
I could write:
jsx
<Box is="div" color="primary" bg="secondary" p="xSmall">Hello</Box>
And all the color background and padding (p) would be retrieved from the theme object, then passed down as css prop to target component (can be any tag, defined via is)
I'd like to be able to write something more less like this in my Box component:
function Box(props) {
const { is: Tag, color, bg, ...rest } = props;
return consume((context)=> {
const theme = context.theme;
return <Tag {...rest} css={{ color: theme.color[color], background: theme.color[bg]}} />
});
}
Is that make sense?
@tadeuszwojcik You can provide a function to the css prop to get the theme like this.
function Box(props) {
const { is: Tag, color, bg, ...rest } = props;
return (
<Tag
{...rest}
css={theme => ({
color: theme.color[color],
background: theme.color[bg]
})}
/>
);
}
@mitchellhamilton ha! thanks! I've over-complicated this one it seems! so easy :)
Ok :) thanks and bravo for this great lib.
It's November right now, where is the doc ?
I tried to migrate, my styled() wrapped components don't recognize props.theme anymore
Most helpful comment
@tadeuszwojcik You can provide a function to the css prop to get the theme like this.