feat(value-list-item): add new slot labelled as content-center to replace label/description (#3373)

[y0n4]

Related Issue: #3373

Summary

In the case of when the label and description prop is not utilized, there is a custom content slot that can replace the area of the label/description. This way there won't be a big gap in the middle of the component and no need to squish more content to the other slots like actions-start or actions-end. Label/description or content slot must be provided while using the calcite-pick-list-item component

Content slot will take precedence over label/description if provided.
When the list item is interactive and has content slot, the item can be selected if user clicks outside of the content slot.

Before: you can see that there is an empty gap where the label/description is supposed to be and the user wants to include more content

After: now label/description can be replaced with custom content and there is no longer that empty gap

[driskull]

@y0n4 can you add a test for this? Maybe a screener update to show an item without a title?

[jcfranco]

@asangma Can you confirm if having no content still fits with the standardized item layout pattern

[action-start][content-start][content][content-end][action-end])

?

[asangma]

If I understand correctly, you want to know if no label or description is added, the actions-start and actions-end slots should fill the available space in, yes?

As far as that layout pattern, that' pretty much it, though the full pattern wraps the content slots and node in a button.
[actions-start] [ button [content-start][content][content-end] ] [actions-end]

[y0n4]

@asangma yes that is correct. Should the component require a label or can it be empty and the slots will stretch the rest of the space? There is that whole empty gap around the label area because it is expecting a label. The e2e test is also expecting a label as well so if it's not required, the test will fail

It is a bit confusing since label prop is required in calcite-value-list-item (which is utilized in this issue use case) but not required in calcite-pick-list-item which is basically the entire structure of calcite-value-list-item component. The consistency is a bit off

[asangma]

Seems like we should just require it in PickListItem.

[asangma]

Because the request is focused on allowing custom content in the main content area, I suggest that we

• do not require label
• we render the default slot in the content area

This way a user can do like

<calcite-pick-list-item>
  <calcite-action slot="actions-end"></calcite-action>
  <calcite-label>
    <calcite-input />
  </calcite-label>
  <!-- or whatever -->
</calcite-pick-list-item>

[asangma]

@driskull I'm thinking that if the content slot is used, we just render whatever they put in there and don't do anything with label props or click handlers. Basically, if you wanna take control of that, you have control over behavior.

[driskull]

@asangma I think some more research needs to happen here. The role of a pick-list-item is a checkbox.

If a user slots an input inside of a pick-list-item, then its basically like putting a input inside a checkbox.

If we remove the checkbox role, then it's no longer able to "pick".

The purpose of this slot needs to be clarified and limited otherwise we are setting users up for a11y failures and breaking changes down the road for us.

[driskull]

If a input needs to be slotted, it needs to go next to the checkbox role, not inside it.

[driskull]

@benelan @jcfranco we might need to require more usage of the accessible test helper. So that when a new slot is added its a11y is tested. Probably a convention update here.

[jcfranco]

Apologies for not chiming in sooner. I'll review first thing tomorrow.

[asangma]

@jcfranco @driskull I think we need to revisit the design and implementation of this. Chatted with @y0n4.

[asangma]

Here is the basic concept. I'd like to run the UI (see below) through a design review.

I have some initial UI stuff here.

[driskull]

Maybe two separate item types since the UI will be different depending on a slot being used? I'm not sure where we draw the line and say its a separate item component rather than it renders differently when things are slotted.

[asangma]

I considered that. However, one of the workflows/UX in question is being able to do some kind of inline editing, e.g. temporarily replace the standard content with an input.

[asangma]

I'd be willing to remove the select/deselect button when "content" slot is used.
That'd be the most straightforward approach I think.

[macandcheese]

At what point is a regular list item more apt?

[asangma]

@macandcheese A dev could do that, but ListItem doesn't come with all the single-select, multi-select and prescribed icons (check vs radio).

[asangma]

Really, this is a pattern we use in a couple other places, i.e. having a slot that overrides a main content area.

That being said, I'm open to other solutions for the initial request to have inline editable text.

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity. Please close your PR if it is no longer relevant. Thank you for your contributions.

[jcfranco]

Blocking and freezing this one until we flesh out the details for the action/content slot pattern epic. @y0n4 @asangma @driskull @macandcheese Thanks for the time and energy on this, but the implementation of this brought up some items that needed to be well-defined first.

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity. Please close your PR if it is no longer relevant. Thank you for your contributions.