-
Notifications
You must be signed in to change notification settings - Fork 2
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
Theme provider #33
Theme provider #33
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very namespace. Much theme 🐕
Couple questions, for me to understand some specific decisions.
|
||
Themes will merge with same versions of emotion | ||
UIKit theme is namespaced | ||
Please use as last theme provider |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"last" may require a bit more elaboration... does this mean the provider needs to be nested as a child of all other (external) theme providers?
e.g. Arranger theme provider. Curious about the results for that overlap, if it was to ever happen 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes 'last' is rather vague. To be honest it doesn't matter too much.
Once the same emotion version is in use it will be merged anyway, thus the namespacing.
so:
<ArrangerTProvider theme={{colors: blue}>
<UIKitTProvider theme={{colors:blue}}>
.....
theme
would look something like:
{
colors: blue;
uikit: {colors:blue}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that makes all the sense in the world.
followup question: if your provider inherits { colors: blue, uikit: null }
from a parent provider?
and if that overwrites the default theme, how do the components respond? e.g. theme.uikit.colors.blue
?
|
||
expect.extend(matchers); | ||
|
||
export {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I figure this is boilerplate standard... but out of curiosity, what's it function?
may be useful to add a comment (e.g. within the curlies) to explain something so eager beavers like myself don't go deleting that line thinking it's cruft.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea. It's just to make TS happy so it's a valid module seen as we're not exporting anything, just setting up some stuff
"react": "16.x.x || 17.x.x", | ||
"react-dom": "16.x.x || 17.x.x" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may be wrong, but react
and react-dom
may still need to be peer deps, so that React doesn't throw mismatching versions for hooks.
That's happened to me while using npm/yarn link
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're right. This has proven to be a big issue so I'm tackling this in a seperate PR.
"ts-node-dev": "^1.1.8", | ||
"tsc-watch": "^4.5.0", | ||
"typescript": "^3.9.5" | ||
"typescript": "^4.6.2" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💪
@@ -23,16 +23,16 @@ import styled from '@emotion/styled'; | |||
import clsx from 'clsx'; | |||
|
|||
const Ul = styled('ul')<{ theme?: any }>` | |||
${({ theme }) => css(theme.typography.paragraph)}; | |||
${({ theme }) => css(theme.uikit.typography.paragraph)}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does the theme system allow for the theme to be disabled -> missing, or overwritten with a custom theme that has an entirely different shape?
in that case these chains may fail with cannot find X of undefined
.
theme?.uikit?.typography?.paragraph
covers that, but could also use having a fallback/default value if it the chain ever fails.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of a fallback. This is an issue we currently face in our projects so it's not an introduced issue but could be a lovely improvement!
A missing theme will default to a default theme.
As for a different shape TS will yell at you but it could happen. I like having a very defined interface for anything we are passing to uikit. There's a lot of improvement to be made on this. plenty of places where we say we're using a theme color but then actually just import a color, so it's never actually dynamically theme-able to the outside. I will create a ticket with this.
|
||
const ThemesWrapper = ({ projectTheme = {}, uikitTheme = undefined, children }) => ( | ||
<ProjectThemeProvider theme={projectTheme}> | ||
{/*@ts-ignore*/} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sheer curiosity: what checks is this avoiding?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is something I ended up fixing :)
will double check and update. TS didn't like the shape of my theme prop
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 yeah, the TS inference vs annotation gets finicky, doesn't it?
@@ -44,4 +36,4 @@ const ThemeProvider: React.ComponentType<{ theme?: keyof typeof themes }> = ({ | |||
}; | |||
|
|||
export default ThemeProvider; | |||
export const useTheme = () => React.useContext(ThemeContext as React.Context<typeof defaultTheme>); | |||
export { useTheme } from '@emotion/react'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0% a criticism or complaint (as I get why this export is happening)... and yet, honestly, this pattern makes me uneasy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would love to discuss more :) are you thinking use a regular context we create?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. I did take that route in Arranger to prevent headches, but I'm not advocating for that approach.
It's just the exporting a third party module what doesn't seem right to me, but I may be being too picky.
Again, I know why it's needed, given Emotion's "special needs". Just thinking there may be other ways to have Emotion play along without this railguard enforcement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be cleaned up. I think it'll work just fine if useTheme
is directly imported from emotion
where ever it is needed.
This re-export was mostly a "don't break more than you need to" change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fair enough!!! "taking one day at a time" 👍 I like it.
@@ -12,7 +12,8 @@ | |||
"moduleResolution": "node", | |||
"resolveJsonModule": false, | |||
"isolatedModules": false, | |||
"jsx": "preserve", | |||
"jsx": "react-jsx", | |||
"jsxImportSource": "@emotion/react", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice! React 17 runtime! 🚀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this was a "fun" one... a lot of heartache between babel and jest until finally stumbling on jsxImportSource which has the added boon of not needing the pragma to be added everywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep. stumbled on this one myself a while ago. happy you were able to make it work!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 🚢
Description of changes
NB: most of these files are just updating our
theme.foo
references totheme.uikit.foo
Lots of Theme editing
Type of Change
Checklist before requesting review: