-
Notifications
You must be signed in to change notification settings - Fork 887
refactor: remove theme "color palettes" #11314
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
Conversation
}, | ||
}, | ||
} as ThemeOptions); | ||
|
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.
Big fan of getting rid of all this
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.
Looks good! Big fan of the consolidation for the MUI-specific stuff
Just had one comment about possibly removing the need for any
types
@@ -1,3 +1,18 @@ | |||
/* eslint-disable @typescript-eslint/no-explicit-any | |||
-- we need to hack around the MUI types a little */ |
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 looks like we can get a little more specific with the type assertions by doing something like this:
type MuiOverrideStyleKey = keyof ComponentNameToClassKey;
styleOverrides: {
["sizeXlarge" as MuiOverrideStyleKey]: {...}
}
I pulled down the branch and tried it out, and it seems like it silences the compiler warnings. You know more about the theming set up than I do, though. I'm normally pretty skittish around any
types, but do you think a change like this is even worth it?
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.
my concern about that is that it's technically lying to the compiler 😅 we'd be casting it as something it is not, and it would read as "trust me, I know what I'm doing", whereas using any
is hinting a bit more at "this should make you nervous because something going on here is wrong and we should maybe fix it more rigorously later"
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 genuinely intend to improve this in the new year. I hope I've earned a bit of trust that I'm the type of dev who will actually go back and clean up debt, lol.)
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 guess the way I see it is that both ways are lying to the compiler, but only the any
approach completely turns the compiler off
I'm cool if you want to keep things as-is, but if anything, I feel like the way to split the difference would be to rename the type to something like HackyMuiOverrideStyleKey
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.
Oh, sorry. For some reason your second comment didn't come in when I was replying
To be clear, I do trust you – I didn't realize that this was a temp solution, and I'm being an ass
buffet style is super bug prone, much better to have curated colors with specific purposes