Skip to content
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

Merged
merged 24 commits into from
Mar 22, 2022
Merged

Theme provider #33

merged 24 commits into from
Mar 22, 2022

Conversation

ciaranschutte
Copy link
Contributor

@ciaranschutte ciaranschutte commented Mar 21, 2022

Description of changes

NB: most of these files are just updating our theme.foo references to theme.uikit.foo

Lots of Theme editing

  • sets up Jest + React Testing Library + Babel correctly to run tests and not break build. don't break build.
  • adds a Template component for testing but also as a... well.. component template
  • removed indexing. there's no 'i' in theme. (just a joke comment to ensure we're all reading every line)
  • namespaces the uikit theme because it will likely be used with other theme providers (helps to avoid variable collisions)
  • updates to readme

Type of Change

  • Bug
  • Styling
  • New Feature

Checklist before requesting review:

  • Design (select one):
    • Matches design:
      • component sizes, spacing, and styles
      • font size, weight, colour
      • spelling has been double checked
    • No design provided, screenshot of changes included in PR
    • No changes to UI
  • UI Kit (select one):
    • New Components with storybook stories created
    • Modified Existing components and updates stories
    • No new UIKit components or changes
  • Feature is minimally responsive
  • Manual testing of UI feature
  • Add copyrights to new files
  • Connected ticket to PR

@ciaranschutte ciaranschutte changed the base branch from develop to v2 March 21, 2022 18:29
@ciaranschutte ciaranschutte marked this pull request as ready for review March 21, 2022 19:26
Copy link
Member

@justincorrigible justincorrigible left a 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
Copy link
Member

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 🤔

Copy link
Contributor Author

@ciaranschutte ciaranschutte Mar 22, 2022

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}
}

Copy link
Member

@justincorrigible justincorrigible Mar 22, 2022

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 {};
Copy link
Member

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.

Copy link
Contributor Author

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

Comment on lines -28 to -29
"react": "16.x.x || 17.x.x",
"react-dom": "16.x.x || 17.x.x"
Copy link
Member

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.

Copy link
Contributor Author

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"
Copy link
Member

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)};
Copy link
Member

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.

Copy link
Contributor Author

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*/}
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

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';
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

@justincorrigible justincorrigible Mar 22, 2022

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.

Copy link
Contributor Author

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.

Copy link
Member

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",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice! React 17 runtime! 🚀

Copy link
Contributor Author

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.

Copy link
Member

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!

Copy link
Member

@justincorrigible justincorrigible left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 🚢

@ciaranschutte ciaranschutte merged commit 4f55c88 into v2 Mar 22, 2022
@ciaranschutte ciaranschutte deleted the theme-provider branch March 22, 2022 21:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants