-
Notifications
You must be signed in to change notification settings - Fork 14.6k
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
feat: massive theming-related PR #31590
base: master
Are you sure you want to change the base?
Conversation
Based on your review schedule, I'll hold off on reviewing this PR until it's marked as ready for review. If you'd like me to take a look now, comment
|
f1c7929
to
43452ff
Compare
97e182d
to
0655910
Compare
1ca8e6e
to
6c6532e
Compare
003f992
to
1652452
Compare
Chiseling at #31590 and bringing what's atomically committable out of there. This simply adds eslint checks to pre-commit. Note that: - it requires having run `npm i` in superset-frontend - it's set up to NOT run in CI as part of the pre-commit validation workflow, since we run eslint more formally in another workflow Why doing this? Currently it's common to forget to run `npm run lint` prior to committing/pushing, so people can waste time waiting for CI to fail where it could be caught easily. It's nice to have pre-commit do the check itself because it will only evaluate the files that have changed, making it much faster than running a full lint run against all files.
…rt/e2e.ts While working on #31590, I noticed that `expect` was not properly imported. It was using it from global for some unknown reason.
1652452
to
f89a23b
Compare
Chiseling at #31590 that has gotten big / unruly, in this PR is a refactor of Alert-related components, going vanilla AntD. Also. Deprecating colors.alerts since it's ambiguous/redundant with warning/error and does not exist in antd-v5
Chiseling at #31590 that has gotten big / unruly, in this PR is a refactor of Alert-related components, going vanilla AntD. Also. Deprecating colors.alerts since it's ambiguous/redundant with warning/error and does not exist in antd-v5
Chiseling at #31590 that has gotten big / unruly, in this PR is a refactor of Alert-related components, going vanilla AntD. Also. Deprecating colors.alerts since it's ambiguous/redundant with warning/error and does not exist in antd-v5
Chiseling at #31590 that has gotten big / unruly, in this PR is a refactor of Alert-related components, going vanilla AntD. Also. Deprecating colors.alerts since it's ambiguous/redundant with warning/error and does not exist in antd-v5
Chiseling at #31590 that has gotten big / unruly, in this PR is a refactor of Alert-related components, going vanilla AntD. Also. Deprecating colors.alerts since it's ambiguous/redundant with warning/error and does not exist in antd-v5
Thanks for reporting the visual issues, planning on solving the bulk of them (and other ones we find) prior to merging this. |
|
@mistercrunch Processing your ephemeral environment request here. Action: up. |
e0db918
to
2961115
Compare
a879aaf
to
9a7d632
Compare
f529ad5
to
7e56fe5
Compare
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.
Beautiful!
import { supersetTheme, ThemeProvider } from '@superset-ui/core'; | ||
import { AntdThemeProvider } from '../src/components/AntdThemeProvider'; | ||
import { themeObject } from '@superset-ui/core'; | ||
import { theme } from 'src/preamble'; |
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 like we don't need theme
in this file?
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 weird, guessing eslint might not be covering this folder...
|
||
private static readonly sizeMap: Record<FontSizeKey, string> = { | ||
xs: 'fontSizeXS', | ||
s: 'fontSizeSM', |
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.
Curious why fontSizeSM
and not jut fontSizeS
. My brain reads this as `Font size: small-medium"
Similar for fontSizeLG
instead of just fontSizeL
.
It would also align with FontSizeKey
.
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 hear you, had similar thoughts but decided to commit to the AntD token semantics that are well documented and supported across AntD components and beyond. More on it here -> https://ant.design/docs/react/customize-theme .
Oh I get that we could match their 2 letters code in FontSizeKey
, but I think it's defined elsewhere and used across places (didn't grep, but afraid to find I'd have to touch a bunch of files). Could be done as a follow up as this is all still an internal API
private constructor({ | ||
seed, | ||
antdConfig, | ||
isDark = false, |
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 might be over-engineering but I was wondering if this just be an enum, mode = ThemeMode.DARK
, for example. Then in the future we could have other modes, like high-contrast.
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.
Dark is a pretty funky construct where based on this we pass in an AntD darkAlgorithm
object in ThemeConfig
. Similarly they offer a compact
algorithm that can be composed with darkAlgorithm
, so you can do
const themeConfig = {
seed,
algorithm: [darkAlgorithm, compactAlgorithm]
}
Meaning some of these things are not exclusive, which is a bit funky.
The constructor here allows for different combos through static methods, like Theme.fromSeed(seed, isDark)
and another Theme.fromAntdConfig(config)
. We still need isDark
to support legacy logic around theme.colors.primary.dark3
.
Could simplify/cleanup later, and until the public API settles. Working with all this, I think standardizing with an extended AntD config makes most sense. If you want a dark theme, give me a dark antdconfig....
// const mergedTheme = merge({}, this.theme, partialTheme); | ||
// const isDark = tinycolor(mergedTheme.colorBgBase).isDark(); | ||
// const antdConfig = Theme.getAntdConfig(systemColors, isDark); | ||
// this.updateTheme(mergedTheme, antdConfig, isDark); |
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.
Remove 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.
mmmh, yeah that one is really a TODO: allow people to override the theme through THEME_OVERRIDES in config.py
. Needs more thinking around how we allow people to set the theme from a config object. A bit of an artifact from previous theme handling, but it remains hooked in from bootstrap_data in src/preamble.ts
.
Good to resurface this as it's a pretty important hanging thread in the whole theming saga. Do we want to allow people to set the theme through config? build time? in-UI?
I'm thinking for now I might want to simply call this method setTheme
, and pass what's in the config.py/bootstrap_data as a seed
. Pure antd config aren't serializable as they can contain algorightm as object reference, which we can't reference from the backend.
Needs more thinking, but I'm thinking I'll probably do something simple so that it's possible to set the theme from config.THEME_OVERRIDES
@@ -374,7 +374,7 @@ export default styled(BigNumberVis)` | |||
.kicker, | |||
.header-line, | |||
.subheader-line { | |||
opacity: ${theme.opacity.mediumHeavy}; | |||
opacity: 60%; |
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.
Curious of why we're hardcoding opacities now?
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 that was a bit of a hard slash (machete in the jungle), here's the rationale for slashing/hard-coding it:
- The antd theming system doesn't specify presets for opacity, probably because there's no clear aligned standards or design guidelines to follow here. Case-by-case might be better
- use/reuse across the codebase was minimal, with hard-coded widespread, token reuse not common
- is there real value around having set values? what should they be? does it help to use midHeavy over 80% or 70%. Would a "themer" want to alter these values centrally ,like "oh I want all the mediumHeavy to be a little lighter in my environment"?
@@ -151,7 +151,7 @@ export default function TimezoneSelector({ | |||
return ( | |||
<Select | |||
ariaLabel={t('Timezone selector')} | |||
css={{ minWidth }} | |||
// css={{ minWidth }} |
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.
// css={{ minWidth }} |
fb1d6da
to
443f805
Compare
8224662
to
1d52ecb
Compare
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.
There are some nits(leftover comments, naming etc.) but it looks good
const bg = isDark ? '#FFF' : '#000'; | ||
const fg = isDark ? '#000' : '#FFF'; |
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.
Naming here seems a bit off. bg is white when isDark?
|
||
const styled = emotionStyled; | ||
|
||
// launching in in dark mode for now while iterating |
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.
// launching in in dark mode for now while iterating |
} | ||
} | ||
|
||
/* eslint-enable theme-colors/no-literal-colors */ |
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.
/* eslint-enable theme-colors/no-literal-colors */ |
a713bdf
to
abe8c8d
Compare
Excuse the large PR, but this is fairly tangled up, and working on fixing up theming probably requires some massive PRs as it's really hard to proceed PR-by-PR - especially during the holiday break...
Introducing less handlebars templates
First. Clearly we should move away from
less
and commit to emotion/antd for theming Now deleting the less files is going to be difficult. In the meantime, I wanted to provide a way for less files to source from the main theme object. I decided to go with handlebars since that should be part of the build process.Considerations:
.less
files from the repo, and make sure they are dynamically generated on every builds. In the meantime I thought I'd leave them here, and we can instruct people to alter.less.hds
files and runnpm run compile-less
on demand, if/when altering the main themeLarge refactor - what's in this PR?
antd
theme tokenswhat's NOT in this PR? - yet to come
theme.antd
referencing in emotionThemeConfig
as the theme setup, this will require more moving from legacy theme object to antd