-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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: Update Text and Heading Themes for New DS #10606
feat: Update Text and Heading Themes for New DS #10606
Conversation
✅ ethereum-org-website-dev deploy preview ready
|
051c112
to
97ce437
Compare
@nloureiro Please view the Chromatic UI Tests check and storybook. Of course, this is considered a priority to be able to properly work on other components that need it. One thing outstanding on here: should a margin bottom be a part of the |
bf889e7
to
adf11e6
Compare
Interesting point @TylerAPfledderer. IMO for this first iteration we should not add those margins to the Heading component. Later, as we migrate the different layouts or pages (previously defined in the DS), we are going to start detecting patterns with these margins, and we should decide then if we add them to the Headings or if we do something else, like using |
}, | ||
a: { | ||
color: "primary.base", | ||
textDecoration: "underline", | ||
}, | ||
// should be replace with https://chakra-ui.com/docs/components/text | ||
p: { | ||
margin: "0px 0px 1.45rem", |
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.
Now, looking at the preview deploy, I see that we kind of depend on this margin to avoid having to refactor all the codebase. I'd say that for the Text
component we add this button margin. What do you think @nloureiro and @TylerAPfledderer?
Note for context for @nloureiro. This Text
component represents the p
tag, the paragraphs in html.
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.
@pettinarip fair point!
So for example, with the Homepage hero where this margin would be used against the CTA button "Explore Ethereum", when working on the new heroes I took a different approach, whereby I structured the Header and text under one flex stack, and then that grouping with the button at a higher level stack, and used the gap
or spacing
prop to define the "margin" between the different texts and between the paragraph and the button.
// Something to this effect
<VStack spacing='4'>
<VStack spacing='2'>
<Heading />
<Text />
</VStack>
<Button />
</VStack>
I should ask then what would best practice be here? In my description above, this approach using the Flexbox gap
property to define the margins between content instead of using the margin
prop.
And I would consider in addition to the above the idea of using margin
only when we are stacking paragraphs, with a defined :first- or :last-of-type selector so that only margin is defined between the paragraphs, but not added above the first or below the last of the stacked siblings.
So:
"p:not(:last-of-type)": {
mb: "2" // or some other token value
}
However, I also understand that margin has to be well defined for the mdx file parsing because you have no ability to isolate groups of text elements into neatly packaged boxes. So I would want to figure out what the best practice should be to keep usage in MDX pages inline with the page layouts that do not use MDX.
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.
Using gap
and spacing
is correct and expected as the best way to go looking ahead.
Now, talking about the current problem and thinking about how to support the old margins, I think that the best way to go is by leaving the Text
component as it is and creating a new temporary one called OldText
that would have the old margins.
Following this idea
- the
Text
component would be used in all new implementation - the
OldText
would be marked as deprecated and would be used in the rest of the old/current implementations.
The OldText
component might be something as simple as this
function OldText(props) {
return <Text margin={oldDefaultMargins} {...props} />
}
With that new component in place, I could go and refactor the entire codebase by importing the OldText
and adding those changes to this PR.
Then, as you migrate the new components as the Hero
, you can start using and importing the native Text
.
Does it make sense?
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.
@pettinarip Ok! So using the OldText
component for the MDX files too, correct?
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.
Correct.
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.
@pettinarip I've pushed this new component here.
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.
Thanks. I'll refactor the code to use that component instead of the Text
.
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.
Sounds good!
@@ -0,0 +1,48 @@ | |||
import { defineStyle, defineStyleConfig } from "@chakra-ui/react" | |||
|
|||
const sizes = { |
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.
@TylerAPfledderer we discussed with Nuno about these sizes and we've updated them to match the same sizes than Chakra https://chakra-ui.com/docs/styled-system/theme#typography
Now, md
should be the same md
as in Chakra (1 rem). Same with the rest.
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.
@pettinarip to clarify, this is just regarding the Text
component? It looks like the sizes for the Heading
component have not changed (which is to be expected since they are currently inline with the Chakra defaults)
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.
Also need clarification regarding the body copy with this update. Marked a question in the figma file as I found a discrepancy.
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.
Correct @TylerAPfledderer. The Heading
has not suffered any update.
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.
@pettinarip this is now updated in the PR
@pettinarip looks like Chromatic wasn't triggered with the new stories. @nloureiro yes to this one as well as |
@pettinarip @nloureiro I updated the branch recently, and now the chromatic test and review checks are now available! NOTEI've failed the UI Tests check due to regressions showing from the Card and Slider stories. (Glad they were available!) Therefore, this PR should not merge until those at least can be fixed and shown as properly laid out (i.e. keep to the original spacing and sizing... or close to it). Then approve the UI Tests again and the UI review itself. And this is why we have Chromatic! 🤣
|
@nloureiro @pettinarip this should be good for a review again! |
|
||
const headingScale: Array<HeadingProps> = [ | ||
{ | ||
as: "h1", |
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.
@TylerAPfledderer @pettinarip maybe this is normal, but having 3 times as="h1"
is correct?
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.
@nloureiro I could only assume that the three largest sizes would be reserved for the h1
heading. If that is true, then I would make sure that the story reflected that preference.
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.
🚢
Description
Update theming of the
Heading
andText
components with stories.Related Issue
Part of the Implentation of the DS v1 #9548