feat: #241 init v5 new Tag component

[nurm717123]

Context

There is new v5 tag #241 that will replace the previous (v4) tag component.

note: #269 need to be merged first in order deprecate older component

this pr is to create the new component to replace the previous one

Pull request checklist

Detail as per issue below (required):
[x] new tag component

result preview:

2025-01-17.11-07-30.mov

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for a4e13fd1	✅ 76.47%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (a4e13fd)	Report Missing	Report Missing	Report Missing
Head commit (87eb8ac)	4693	4175	88.96%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#270)	17	13	76.47%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[ksolanki7]

I believe the changes are from the previous PR for Tag component and doesn't require more review feedback on it.
Looks good to me.

[nurm717123]

I believe the changes are from the previous PR for Tag component and doesn't require more review feedback on it. Looks good to me.

yup, just one addition isStandalone props for Tag, for the usage when consumer use it without TagGroup so it render as span instead of li.just let me know if It need more correction and I will update it, thanks.

[kurtdoherty]

@nurm717123 is it really necessary to use <li> items when in the tag group?

[nurm717123]

@nurm717123 is it really necessary to use <li> items when in the tag group?

yes, as I use ul and li pattern for TagGroup, because it usually will be used to display list of status, roles, .etc right?, what do you think 🤔 ?

[kurtdoherty]

@nurm717123 are we basing the use of ul and li for the tag group on any a11y research or it just a gut feel? (Nothing wrong with gut feels, just seeking clarity).

I'm not sure many devs will remember to supply an isStandalone prop to a Tag when they use it outside a tag group. I think we should either be handling that automatically for devs, or perhaps allowing devs to decide what DOM element the tag group and tag render as.

[nurm717123]

@nurm717123 are we basing the use of ul and li for the tag group on any a11y research or it just a gut feel? (Nothing wrong with gut feels, just seeking clarity).

yeah, I done a research and I came up with 2 choice

1. use ul and li
2. use div with role (e.g list and list-item)

and my consideration is, even if we use div, I think the component still need to know whether it is used as standalone or group, to provide correct role.

I'm not sure many devs will remember to supply an isStandalone prop to a Tag when they use it outside a tag group. I think we should either be handling that automatically for devs, or perhaps better, allowing devs to decide what DOM element the tag group and tag render as.

yeah, I agree.

[kurtdoherty]

Okay, thanks for clarifying 👍

I'm okay with either option you mention, I just think we should either handle the "inside tag group" vs "solo tag" decision making automatically for devs OR force them to think about the DOM elements themselves (e.g. via an as="span" or as="li" required prop) instead of a more abstract concept like "standalone".

Edit: to be clear though, this is not blocking feedback. It's easy enough to deprecate isStandalone in future if we do the extra work. Happy for you to move ahead as is if you want to keep moving.

[nurm717123]

Okay, thanks for clarifying 👍

I'm okay with either option you mention, I just think we should either handle the "inside tag group" vs "solo tag" decision making automatically for devs OR force them to think about the DOM elements themselves (e.g. via an as="span" or as="li" required prop) instead of a more abstract concept like "standalone".

Edit: to be clear though, this is not blocking feedback. It's easy enough to deprecate isStandalone in future if we do the extra work. Happy for you to move ahead as is if you want to keep moving.

Thanks, I think I will merge it first, and I will create another ticket to discuss how to approach it 👍

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for a4e13fd1	✅ 92.86%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (a4e13fd)	Report Missing	Report Missing	Report Missing
Head commit (ed9d1e0)	4690	4175	89.02%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#270)	14	13	92.86%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

Footnotes

1. Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct. ↩

[nurm717123]

Okay, thanks for clarifying 👍

I'm okay with either option you mention, I just think we should either handle the "inside tag group" vs "solo tag" decision making automatically for devs OR force them to think about the DOM elements themselves (e.g. via an as="span" or as="li" required prop) instead of a more abstract concept like "standalone".

Edit: to be clear though, this is not blocking feedback. It's easy enough to deprecate isStandalone in future if we do the extra work. Happy for you to move ahead as is if you want to keep moving.

instead of creating new ticket, I think I will work on it as part of current ticket and add a new comment to propose the approach, please have a look here