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

Extend Link with Styling API, update documentation #1028

Merged
merged 7 commits into from
May 19, 2023
Merged

Conversation

lyzadanger
Copy link
Contributor

@lyzadanger lyzadanger commented May 17, 2023

Depends on #1029

This PR pilots the styling API proposed in https://docs.google.com/presentation/d/1uTHdWrXKqVuivMI6Z3JR91ZP-Qb_0Ki2fvIAht7JSbk by updating the Link component and a whole lot of related documentation in the pattern library.

There's maybe 50 lines of actual functional change here and a whole bunch of supporting documentation and formatting.

The basic chunks of this work are:

  • Adjustments to some Library components to fix a few glitches (margins, mostly) and add a way to format API props more cleanly (These were chunked off into a separate PR Pattern library: Adjust margins, add Info, InfoItem components #1029)
  • Updates to Link and its pattern-library documentation
  • Restructure of the "Using Components" page: Add the API details of the Styling API
  • Replacement of the "Customizing Components" page with a "Styling Components" page. This covers how to use the Styling API

This work is additive, not breaking.

Testing

I suggest checking out this branch, running make dev and visiting the:

TODOs

  • Determine appropriate tests to add for this

Future enhancements that would make this better

  • Auto-generated permalinks and tables of contents would make pattern-library pages easier to navigate
image

Comment on lines 50 to 52
// underline
// TODO: Underline should be controlled by `variant` and should default
// to `always`
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 want to acknowledge that underline is a problematic prop that doesn't fit into this model neatly. Which means I think it should go in the short future.

Copy link
Member

Choose a reason for hiding this comment

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

My intuition is that a single enum "variant" is probably not going to be enough to accommodate the different "standard"/built-in styles that a component may have. I wouldn't be surprised if we need flag props for example to turn certain elements of the standard style on/off. If the component is unstyled or using a custom variant or size, then these props wouldn't apply though.

{...htmlAttributes}
classes={classnames(
'rounded-sm',
// NB: Base classes are applied by LinkBase
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not anymore. This is a good thing because even this small abstraction caused a regression in one of these components recently.

@@ -63,20 +63,26 @@ function Heading({
}: LibraryHeadingProps) {
if (level <= 2) {
return (
<h2 className="text-3xl text-slate-600 font-bold" {...htmlAttributes}>
<h2
className="text-3xl text-slate-600 font-bold mb-4"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Margin fixes. If the smattering of changes in this module feel noisy, you might do better reviewing commit by commit.

@@ -124,7 +130,7 @@ function Section({
{intro && (
<div className="text-base space-y-3 leading-relaxed">{intro}</div>
)}
<div className="leading-relaxed">{children}</div>
{children}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removing containing element to fix margins.

</Library.InfoItem>
<Library.InfoItem label="type">
<code>
{'preact.JSX.HTMLAttributes<T extends HTMLElement>'}
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'm not at all convinced I got "types" right in these docs so I'm open to feedback.

Copy link
Contributor

Choose a reason for hiding this comment

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

I would say this is intuitive enough.

>
<Library.Pattern title="Props API">
<Library.Section
id="presentational-components-styling-api"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a few IDs by hand in these pages so I could cross link. Hope to automate these soon.

disable variant styling.
</Library.InfoItem>
<Library.InfoItem label="type">
<code>{`'custom' | string`}</code>
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'm 99% sure this isn't the way I should express this "type".

Copy link
Contributor

@acelaya acelaya left a comment

Choose a reason for hiding this comment

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

I like how it looks like 🙂

Comment on lines 48 to 56
{
// color
'text-brand hover:text-brand-dark': color === 'brand', // default
'text-color-text-light hover:text-brand': color === 'text-light',
'text-color-text hover:text-brand-dark': color === 'text',
'focus-visible-ring rounded-sm': styled,
// underline
// TODO: Underline should be controlled by `variant` and should default
// to `always`
'no-underline hover:no-underline': styled && underline === 'none', // default
'underline hover:underline': styled && underline === 'always',
'no-underline hover:underline': styled && underline === 'hover',
},
Copy link
Contributor

@acelaya acelaya May 18, 2023

Choose a reason for hiding this comment

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

Since styled is a condition for each one of the styles, perhaps we could consider a different formula.

className={classnames(
  {
    'focus-visible-ring rounded-sm': styled,
  },
  styled && {
    'no-underline hover:no-underline': underline === 'none', // default
    'underline hover:underline': underline === 'always',
    'no-underline hover:underline': underline === 'hover',
  },
  // [...]
)}

It would allow not having to add the condition every time, but perhaps it makes it less clear, or too subtle. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, I like that. I did go look up classnames API and gave it a think, but this syntax didn't occur to me!

@lyzadanger lyzadanger changed the base branch from main to pattern-library-improvements May 18, 2023 13:34
@codecov
Copy link

codecov bot commented May 18, 2023

Codecov Report

Merging #1028 (cbb35e2) into main (9d95fc0) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main     #1028   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           53        53           
  Lines          709       715    +6     
  Branches       246       251    +5     
=========================================
+ Hits           709       715    +6     
Impacted Files Coverage Δ
src/components/navigation/LinkBase.tsx 100.00% <ø> (ø)
src/components/navigation/Link.tsx 100.00% <100.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

Base automatically changed from pattern-library-improvements to main May 18, 2023 13:44
Copy link
Member

@robertknight robertknight left a comment

Choose a reason for hiding this comment

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

Generally LGTM. If I understand the intended use of variant, I do suspect we will find that a single variant value may not be enough to express commonly used knobs/switches that still fit within the scope of a "standard style". A component could say that certain props are only applicable when using particular sizes/variants though, so we don't try to make them work if the component is unstyled or using eg. a custom variant.

Comment on lines 50 to 52
// underline
// TODO: Underline should be controlled by `variant` and should default
// to `always`
Copy link
Member

Choose a reason for hiding this comment

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

My intuition is that a single enum "variant" is probably not going to be enough to accommodate the different "standard"/built-in styles that a component may have. I wouldn't be surprised if we need flag props for example to turn certain elements of the standard style on/off. If the component is unstyled or using a custom variant or size, then these props wouldn't apply though.

@lyzadanger lyzadanger requested a review from acelaya May 19, 2023 13:24
Copy link
Contributor

@acelaya acelaya left a comment

Choose a reason for hiding this comment

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

LGTM

@lyzadanger lyzadanger merged commit 6119b75 into main May 19, 2023
@lyzadanger lyzadanger deleted the styleable-link branch May 19, 2023 13:38
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.

3 participants