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

[Button.js] Update API for HTML standard, simplify attribute naming, & migrate to named slots #217

Merged
merged 56 commits into from
Aug 29, 2024

Conversation

sreidthomas
Copy link
Contributor

WHAT WAS DONE:

Update component API to adhere to HTML standard microsyntaxes, simplify attribute naming conventions, and migrate to named slots with basic markup where possible

ISSUE:

We have some components that handle attribute values in non-standard ways, use non-standard attribute naming conventions, and unnecessarily nest custom components instead of using named slots.

OVERALL TASK / JOB DUTIES:

  1. Update component APIs to adhere to all HTML standard microsyntaxes, including boolean attributes, colors, space-separated tokens, and comma-separated tokens.
  2. Simplify attribute naming conventions by removing data-* prefixes and using existing standard or global attribute names where possible.
  3. Migrate to named slots with basic markup where possible, removing the nesting of custom web components and the use of content passed via attributes in favor of named slots.

ADDITIONAL NOTES:

Nested, custom components should only be used when:

  1. The nested custom component is a standalone component itself. E.g., it's OK to use in a custom component slot.
  2. The nested content requires more than one level of depth in the DOM. Slots cannot support this case.

Each time we update component attributes or migrate to named slots, we'll need to:

• Update the attribute in the component JS implementation.
• Update the attribute definition and Storybook param names in the story file.

Components are distributed in this spreadsheet:

https://is.gd/ETzUCF

Breakdown of individual tasks for each issue:

Task 201: Update component API to adhere to HTML standard microsyntaxes

  1. Identify components with attributes that do not conform to HTML standard microsyntaxes.
  2. Update attribute values to adhere to standard microsyntaxes:
    • For boolean attributes, ensure values are true or false instead of non-standard values.
    • For color attributes, ensure values are valid color representations (e.g., hex, RGB, or color names).
    • For attributes with space-separated tokens, ensure tokens are separated by spaces.
    • For attributes with comma-separated tokens, ensure tokens are separated by commas.

Task 202: Simplify attribute naming conventions

  1. Identify components with attributes that use non-standard naming conventions or unnecessary prefixes (e.g., data-*).
  2. Standardize attribute names by:
    • Removing data-* prefixes for attributes that behave like global or standard element attributes.
    • Using existing global or standard element attribute names where possible.
    • Removing unnecessary prefixes for custom attributes.
    • Ensuring consistency in attribute names across components.
  3. For each updated attribute or migration to named slots:
    • Update the attribute in the component JS implementation.
    • Update the attribute definition and Storybook param names in the story file.

Task 205: Migrate to named slots with basic markup where possible

  1. Identify components that accept content via attributes or use nested custom components unnecessarily.
  2. Migrate to named slots by:
    • Removing nested custom components and using named slots instead.
    • Refactoring components to accept content via named slots instead of attributes.
    • Updating component documentation and examples to reflect the use of named slots.

@sreidthomas
Copy link
Contributor Author

sreidthomas commented May 20, 2024

UPDATE AS OF MAY 20, 2024:

This component is used in the OffcanvasHeader.js file so in order to properly update OffcanvasHeader.js so attributes need to be changed here:

this.closeBtn.setAttribute('data-img-alt', '');
this.closeBtn.setAttribute('data-icon', '');
this.closeBtn.setAttribute('data-close', 'true');
this.closeBtn.setAttribute('data-bs-dismiss', parentID);

In Progress:

Task 202: Simplify attribute naming conventions part 1 & 2

Did more research on standard, global and custom attributes. Here is what I have so far:

  • data-close: Custom attribute (Updated per instruction --> Standardize attribute names by: Removing unnecessary prefixes for custom attributes.)

  • data-link: Custom attribute (Updated per instruction --> Standardize attribute names by: Removing unnecessary prefixes for custom attributes.)

  • data-id: Standard attribute (global attribute) (Updated per instruction --> Using existing global or standard element attribute names where possible. https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/id)

  • data-aria-label: Standard attribute (global attribute) (Updated per instruction --> Using existing global or standard element attribute names where possible. https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes )

  • data-primary: Custom attribute (Updated per instruction --> Standardize attribute names by: Removing unnecessary prefixes for custom attributes.)

  • data-background-color: Custom attribute (Updated per instruction --> Standardize attribute names by: Removing unnecessary prefixes for custom attributes.)

  • data-shape: Custom attribute (Updated per instruction --> Standardize attribute names by: Removing unnecessary prefixes for custom attributes.)

  • data-icon: Custom attribute (Updated per instruction --> Standardize attribute names by: Removing unnecessary prefixes for custom attributes.)

  • data-icon-size: Custom attribute (Updated per instruction --> Standardize attribute names by: Removing unnecessary prefixes for custom attributes.)

  • data-icon-order: Custom attribute (Updated per instruction --> Standardize attribute names by: Removing unnecessary prefixes for custom attributes.)

  • data-hidden-label: Custom attribute (Updated per instruction --> Standardize attribute names by: Removing unnecessary prefixes for custom attributes.)

  • data-img: Custom attribute (Updated per instruction --> Standardize attribute names by: Removing unnecessary prefixes for custom attributes.)

  • data-img-alt: Custom attribute (Updated per instruction --> Standardize attribute names by: Removing unnecessary prefixes for custom attributes.)

  • data-size: Custom attribute (Updated per instruction --> Standardize attribute names by: Removing unnecessary prefixes for custom attributes.)

  • data-extra-classes: Custom attribute (Updated per instruction --> Standardize attribute names by: Removing unnecessary prefixes for custom attributes.)

  • data-label: Custom attribute (Updated per instruction --> Standardize attribute names by: Removing unnecessary prefixes for custom attributes.)

  • data-disable: Standard attribute (global attribute) (Updated per instruction --> Using existing global or standard element attribute names where possible. https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/disabled)

Task 202: Simplify attribute naming conventions part 3

For all the attributes updated in Button.js, the same attributes and params were updated in the Button.stories.js file per instruction --> For each updated attribute or migration to named slots:
• Update the attribute in the component JS implementation.
• Update the attribute definition and Storybook param names in the story file.

@sreidthomas
Copy link
Contributor Author

sreidthomas commented May 21, 2024

QUESTIONS: @maxatdetroit

  1. If the component is not using slots are we still supposed to migrate to named slots?
  2. When you migrate to named slots are we only updating the template and story files? Is there always something specific that needs to be updated with each element besides the template and story files e.g. EventListeners?
  3. When we migrate to named templates do we change how we add styles, varStyles, & bootstrapStyles to the component?
  4. Are we only checking for the tasks with issue 201 in the .js files or the stories.js file too?

@sreidthomas
Copy link
Contributor Author

sreidthomas commented May 21, 2024

CURRENT ISSUES AS OF MAY 21, 2024:

DO THIS ONCE YOU GET TO COD-ICON PR

The cod-button uses cod-icon so the attributes in cod-icon need to be updated to properly reflect the changes in cod-button

NEXT COMPONENT TO START ON --> cod-icon

  • Update the attributes in cod-icon and re-test to make sure cod-button is working correctly with the icons

@sreidthomas
Copy link
Contributor Author

sreidthomas commented May 21, 2024

NEW TASK FOR MAY 21, 2024:

Task 201: Update component API to adhere to HTML standard microsyntaxes

Identify components with attributes that do not conform to HTML standard microsyntaxes. Update attribute values to adhere to standard microsyntaxes:

  • For boolean attributes, ensure values are true or false instead of non-standard values.

  • For color attributes, ensure values are valid color representations (e.g., hex, RGB, or color names).

  • For attributes with space-separated tokens, ensure tokens are separated by spaces.

  • For attributes with comma-separated tokens, ensure tokens are separated by commas.

  • There are no attributes in Button.js file that use comma-separated tokens

@maxatdetroit
Copy link
Member

@sreidthomas

Question 1:

If the component is not using slots are we still supposed to migrate to named slots?

No. If the component isn't using slots, then there is nothing to migrate from.

Question 2:

When you migrate to named slots are we only updating the template and story files? Is there always something specific that needs to be updated with each element besides the template and story files e.g. EventListeners?

Whenever you modify a component's public API (i.e. attribute name, attribute behavior, or component slots), we have to look for all the other places in the design system where that component is used. E.g. for cod-button do a code search for cod-button and see where the button is used in the design system. Anywhere it's used, we have to update which attributes and slots are used to match what we updated (e.g. if cod-modal is using cod-button it may still be using the data-close attribute which should be changed to just close).

Question 3:

When we migrate to named templates do we change how we add styles, varStyles, & bootstrapStyles to the component?

Do you mean named slots? If so, it depends. If the styling changes unexpectedly when we move the content into a slot, then yes, we might have to update the styles to target the elements correctly since they've moved in the component layout.

Question 4:

Are we only checking for the tasks with issue 201 in the .js files or the stories.js file too?

I think the answer to question 2 should answer this question as well but let me know if that's not clear.

@sreidthomas
Copy link
Contributor Author

There are no slots in the Button.js file so Task 205: Migrate to named slots with basic markup where possible is not needed.

@sreidthomas
Copy link
Contributor Author

NOTE TO SELF:

yarn lint & yarn prettier -w "FILENAME" ==> how to fix prettier issue

@sreidthomas sreidthomas requested a review from maxatdetroit July 11, 2024 17:07
@sreidthomas
Copy link
Contributor Author

Can you review this one for me and see if I'm on the right track? I think I have to make changes to the cod-icon in order for this to work correctly but I don't want to start on another component yet @maxatdetroit

Copy link
Member

@maxatdetroit maxatdetroit left a comment

Choose a reason for hiding this comment

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

Yep, definitely on the right track.

I think I have to make changes to the cod-icon in order for this to work correctly

That's not necessarily true. You could leave the cod-icon the same and handle it in a separate PR. That's what I'd recommend, because otherwise this PR will get pretty big. I left a comment about what I mean.

However, you will have to change all the places where cod-button gets used across the design system to use the correct attribute names that you changed. Here's a list of all the places where the button is used:

  1. Places where it's created via HTML markup: https://github.com/search?q=repo%3ACityOfDetroit%2FCOD-Design-System+%3Ccod-button&type=code
  2. Places where it's created via JS DOM API: https://github.com/search?q=repo%3ACityOfDetroit%2FCOD-Design-System+document.createElement%28%27cod-button%27&type=code

src/components/atoms/Button/Button.js Outdated Show resolved Hide resolved
@sreidthomas
Copy link
Contributor Author

Yep, definitely on the right track.

I think I have to make changes to the cod-icon in order for this to work correctly

That's not necessarily true. You could leave the cod-icon the same and handle it in a separate PR. That's what I'd recommend, because otherwise this PR will get pretty big. I left a comment about what I mean.

However, you will have to change all the places where cod-button gets used across the design system to use the correct attribute names that you changed. Here's a list of all the places where the button is used:

  1. Places where it's created via HTML markup: https://github.com/search?q=repo%3ACityOfDetroit%2FCOD-Design-System+%3Ccod-button&type=code
  2. Places where it's created via JS DOM API: https://github.com/search?q=repo%3ACityOfDetroit%2FCOD-Design-System+document.createElement%28%27cod-button%27&type=code

Yes that's what I meant starting another PR for it. But I see that I should keep moving with any components that are using the cod-button

@sreidthomas
Copy link
Contributor Author

Yep, definitely on the right track.

I think I have to make changes to the cod-icon in order for this to work correctly

That's not necessarily true. You could leave the cod-icon the same and handle it in a separate PR. That's what I'd recommend, because otherwise this PR will get pretty big. I left a comment about what I mean.

However, you will have to change all the places where cod-button gets used across the design system to use the correct attribute names that you changed. Here's a list of all the places where the button is used:

  1. Places where it's created via HTML markup: https://github.com/search?q=repo%3ACityOfDetroit%2FCOD-Design-System+%3Ccod-button&type=code
  2. Places where it's created via JS DOM API: https://github.com/search?q=repo%3ACityOfDetroit%2FCOD-Design-System+document.createElement%28%27cod-button%27&type=code

You want me to change the places that are using the old attributes within this same PR @maxatdetroit?

@maxatdetroit
Copy link
Member

Yes that's what I meant starting another PR for it. But I see that I should keep moving with any components that are using the cod-button

@sreidthomas ahh gotchya. Thanks for clarifying.

You want me to change the places that are using the old attributes within this same PR @maxatdetroit?

Yea, let's go ahead and do it in one PR. If we tried to do it in a separate PR, then it'd be difficult to merge the PRs in a safe way (that doesn't break the design system).

@sreidthomas
Copy link
Contributor Author

I believe I covered everything but can you go over to make sure @maxatdetroit

Copy link
Member

@maxatdetroit maxatdetroit left a 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 got most of the places where the <cod-button> is created via HTML, but not the places where the <cod-button> is created via JS DOM API.

Here are the other places we have to change: https://github.com/search?q=repo%3ACityOfDetroit%2FCOD-Design-System%20createElement(%27cod-button%27)&type=code

For example, the data-* attribute names are still used for the buttons here:

this.closeBtn.setAttribute('data-img-alt', '');
this.closeBtn.setAttribute('data-icon', '');
this.closeBtn.setAttribute('data-close', 'true');
this.closeBtn.setAttribute('data-bs-dismiss', parentID);

src/stories/buttongroup.stories.js Outdated Show resolved Hide resolved
src/stories/card.stories.js Outdated Show resolved Hide resolved
@sreidthomas
Copy link
Contributor Author

sreidthomas commented Aug 26, 2024

TO-DO:

Update attributes for these components/files:

  • Alert.js
  • button.stories.js
  • ModalFooter.js
  • Map.js
  • OffcanvasHeader.js
  • ModalHeader.js

Copy link
Member

@maxatdetroit maxatdetroit left a comment

Choose a reason for hiding this comment

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

I left a few comments where I noticed we are updating components incorrectly and conflating button component attributes with other components' attributes. I may have missed some places, so please take a look over the entire PR and see if I missed any similar places.

Also, please test your changes as you make them by viewing and interacting with the components you edit in storybook. I caught these issues because I tested this PR in storybook and noticed the Alert component is broken with these changes.

src/components/atoms/Alert/Alert.js Outdated Show resolved Hide resolved
src/components/atoms/ModalFooter/ModalFooter.js Outdated Show resolved Hide resolved
src/stories/buttongroup.stories.js Outdated Show resolved Hide resolved
Copy link
Member

@maxatdetroit maxatdetroit left a comment

Choose a reason for hiding this comment

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

There's still a handful of places where this comment is still applicable:

I left a few comments where I noticed we are updating components incorrectly and conflating button component attributes with other components' attributes. I may have missed some places, so please take a look over the entire PR and see if I missed any similar places.

Please take another look.

src/components/atoms/ModalHeader/ModalHeader.js Outdated Show resolved Hide resolved
src/components/atoms/OffcanvasHeader/OffcanvasHeader.js Outdated Show resolved Hide resolved
src/components/organisms/Map/Map.js Show resolved Hide resolved
@maxatdetroit maxatdetroit changed the base branch from dev to 2.0.0-alpha1 August 27, 2024 16:51
Copy link
Member

@maxatdetroit maxatdetroit left a comment

Choose a reason for hiding this comment

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

Looks good now!

Btw, don't forget to set the base branch to 2.0.0-alpha1 for the uxds 2.0 PRs. I just updated this one on github.

@sreidthomas
Copy link
Contributor Author

Going back over the code for this component and each task. For 201, we had to update everything to meet HTML Standard, and while studying, I learned that href is standard instead of using link like how we're doing. Or is there a reason why we're using link over href @maxatdetroit?

@maxatdetroit maxatdetroit merged commit 0b8f642 into 2.0.0-alpha1 Aug 29, 2024
5 checks passed
@maxatdetroit
Copy link
Member

Going back over the code for this component and each task. For 201, we had to update everything to meet HTML Standard, and while studying, I learned that href is standard instead of using link like how we're doing. Or is there a reason why we're using link over href @maxatdetroit?

That's a really good catch @sreidthomas . There's no reason why we're using the link attr over href. Let's use href moving forward during the UXDS 2.0 migration.

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.

2 participants