-
Notifications
You must be signed in to change notification settings - Fork 3
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
styled-components.dropdown menu items #616
base: feature/config-provider
Are you sure you want to change the base?
Conversation
|
||
// Common styles | ||
const baseStyles = css` | ||
font-family: ${(props) => props.theme.typography}; |
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 is our only styled component for now, but we will probably want to add a GlobalStyles
provider to get things like basic fonts into all styled components, and it could potentially replace some or all of the global style rules in style.css
if we do that.
width: 100%; | ||
font-size: 14px; | ||
|
||
&&& { |
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.
&& (or here &&&) This is a nice way in sass
/styled-components
to do a "precedence boost" without chasing down lots of antd
class names, and without using !important
which overlooks specificity entirely.
https://styled-components.com/docs/basics#adapting-based-on-props
four: "#25222e", // fka three | ||
five: "#2f2a3c", // fka four | ||
six: "#3b3649", // fka charcoal gray, its purplish... |
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.
Can remove these comments, but in our *migration era* I think these are time savers when juggling old css vars and new color constants
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.
migration era ✨
src/styles/theme/colors.ts
Outdated
export const semanticColors = { | ||
// bg colors | ||
lightBg: baseColors.gray.one, | ||
mediumBg: baseColors.dark.six, | ||
grayBg: baseColors.gray.four, | ||
darkBg: baseColors.dark.four, | ||
lightPurpleBg: baseColors.purple.one, | ||
// text colors | ||
lightBgText: baseColors.dark.one, | ||
lightBgActiveText: baseColors.dark.three, | ||
darkBgText: baseColors.gray.nine, | ||
whiteText: baseColors.white.pure, | ||
// accent colors | ||
primaryPurple: baseColors.purple.six, | ||
activePurple: baseColors.purple.five, | ||
primaryBlue: baseColors.blue, | ||
primaryBorder: baseColors.gray.seven, | ||
sliderColor: baseColors.gray.six, | ||
buttonTextGray: baseColors.gray.five, | ||
tagBg: baseColors.purple.nine, | ||
tagText: baseColors.gray.nine, | ||
}; |
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 these can/will continue to evolve a bit as we dial in all styling, but file now has a basic way of exporting base colors, these semantic colors, and then component specific assignments. Spreading all three into the themeColors
export makes any layer the color hierarchy (base, semantic, component) available via styled components theme props.
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 it make sense to not export base colors directly? That way you push development towards assigning specific semantic colors or component colors instead of relying on the hardcoded color directly.
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.
So, if I'm understanding you I think I do at the bottom of the file?
export const themeColors = {
...baseColors,
...semanticColors,
...componentColors,
};
I'm trying to balance both exporting all the most specific instances of the colors for use wherever they end up being needed, and the feedback I've received on previous PRs to consolidate anything that gets used repeatedly in similar contexts into these semantic variables.
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, that's where I meant!
My question was whether baseColors
should be included, since it allows components to assign specific colors instead of requiring them to go through an alias. This creates a dependency on those colors specifically, and means that changing any of them would potentially have a lot of unintended consequences in the future.
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.
Left a bunch of comments!
|
||
// Common styles | ||
const baseStyles = css` | ||
font-family: ${(props) => props.theme.typography}; |
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 TS pick up that props
is of a specific type, or is it any
? Are you able to specify the type of theme
?
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.
According to intellisense the type isn't any
it's ExecutionContext & object
which I'm not entirely sure about, I can type theme as DefaultTheme
from styled-components in the file where I export it, but that type is already picked up here in this file.
I'm not getting a typescript error, do you type props more explicitly in your implementation of styled-components
in TFE?
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 haven't used the props.theme
before in StyledComponents
, I usually am getting my theme variables out of a context. Just curious if Intellisense/TS picked up the Defaulttheme
type!
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 did, and the ThemeProvider is a essentially a context
const StyledDropdownButton = styled.button` | ||
${baseStyles} | ||
${contentStyles} | ||
`; | ||
|
||
const StyledRouterLink = styled(Link)` | ||
${baseStyles} | ||
${contentStyles} | ||
`; | ||
|
||
const StyledExternalLink = styled.a` | ||
${baseStyles} | ||
${contentStyles} | ||
`; |
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.
✨✨✨✨✨✨
four: "#25222e", // fka three | ||
five: "#2f2a3c", // fka four | ||
six: "#3b3649", // fka charcoal gray, its purplish... |
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.
migration era ✨
src/styles/theme/colors.ts
Outdated
export const semanticColors = { | ||
// bg colors | ||
lightBg: baseColors.gray.one, | ||
mediumBg: baseColors.dark.six, | ||
grayBg: baseColors.gray.four, | ||
darkBg: baseColors.dark.four, | ||
lightPurpleBg: baseColors.purple.one, | ||
// text colors | ||
lightBgText: baseColors.dark.one, | ||
lightBgActiveText: baseColors.dark.three, | ||
darkBgText: baseColors.gray.nine, | ||
whiteText: baseColors.white.pure, | ||
// accent colors | ||
primaryPurple: baseColors.purple.six, | ||
activePurple: baseColors.purple.five, | ||
primaryBlue: baseColors.blue, | ||
primaryBorder: baseColors.gray.seven, | ||
sliderColor: baseColors.gray.six, | ||
buttonTextGray: baseColors.gray.five, | ||
tagBg: baseColors.purple.nine, | ||
tagText: baseColors.gray.nine, | ||
}; |
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 it make sense to not export base colors directly? That way you push development towards assigning specific semantic colors or component colors instead of relying on the hardcoded color directly.
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!
Time estimate or Size
Medium
Advances #601
Problem
Dropdown menu elements can be fussy to style as the base html elements receive different default, focus and hover rules front
ant
Solution
As part of migrating to
ant5
I wanted to start using some CSS-in-JS andstyled-components
is in use in other AICS tools liketimelapse-colorizer
. Setting upstyled-components
during the ant migration makes sense to me, if its something we might like to use.DropdownMenuItem
This file uses
styled-components
to create a uniformly styled element for dropdown menu items, regardless of whether the item is a button, an anchor tag, or a react router link.It applies the common styles and then exposes three different
React.FC
exports for use in the menus.token/theme reorganization
Preferable to use
JS
instead ofCSS
variables in thestyled-components
which led me to once again reorganize the colors and theming.I think this version is better, the complete set of base colors from the Figma style guide is included, a couple base colors have been consolidated, I've reduced redundancy as much as possible, and the whole set of base, semantic, and component colors is available via the
ThemeProvider
StyleProvider
Made a wrapper for the now accumulating styling providers so that
App
doesn't look cluttered.