-
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
[Button.js] Update API for HTML standard, simplify attribute naming, & migrate to named slots #217
Conversation
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:
In Progress: Task 202: Simplify attribute naming conventions part 1 & 2Did more research on standard, global and custom attributes. Here is what I have so far:
Task 202: Simplify attribute naming conventions part 3For 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: |
QUESTIONS: @maxatdetroit
|
CURRENT ISSUES AS OF MAY 21, 2024:DO THIS ONCE YOU GET TO COD-ICON PRThe 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
|
NEW TASK FOR MAY 21, 2024:Task 201: Update component API to adhere to HTML standard microsyntaxesIdentify components with attributes that do not conform to HTML standard microsyntaxes. Update attribute values to adhere to standard microsyntaxes:
|
Question 1:
No. If the component isn't using slots, then there is nothing to migrate from. Question 2:
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 Question 3:
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:
I think the answer to question 2 should answer this question as well but let me know if that's not clear. |
There are no slots in the Button.js file so Task 205: Migrate to named slots with basic markup where possible is not needed. |
NOTE TO SELF: yarn lint & yarn prettier -w "FILENAME" ==> how to fix prettier issue |
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 |
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.
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:
- Places where it's created via HTML markup: https://github.com/search?q=repo%3ACityOfDetroit%2FCOD-Design-System+%3Ccod-button&type=code
- 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 |
You want me to change the places that are using the old attributes within this same PR @maxatdetroit? |
@sreidthomas ahh gotchya. Thanks for clarifying.
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). |
I believe I covered everything but can you go over to make sure @maxatdetroit |
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 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); |
TO-DO:Update attributes for these components/files:
|
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 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.
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'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.
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 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.
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 |
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:
ADDITIONAL NOTES:
Nested, custom components should only be used when:
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
• 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
• 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.
• 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
• 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.