How to label PIE form elements

[xander-marjoram]

We currently label our form components in several different ways:

1. The component has a slot for the label text (e.g., pie-checkbox) but the component styles the text.
2. The component has a dedicated slot for a label (specifically for pie-form-label, e.g., pie-checkbox-group).
3. The component uses pie-form-label internally which has its own styling (e.g., pie-textarea), and pie-form-label's props are populated through props on the parent element. This is also known as "prop drilling".
4. The label is an expected sibling for the form input element (e.g., pie-text-input), aiming to support linking the elements with attributes like for and id.

There may also be other ways that are possible but we aren't currently doing.

To have a consistent experience when using our components, we should agree on a single approach, making sure that the one we choose is accessible and easy for developers to work with.

[jamieomaguire]

Thanks for raising this!

I am not very fond of prop drilling. It's messy and adds tech debt to keep interfaces in sync as components evolve.

Slots might be my preferred approach, but as we've discussed in the past they are prone to misuse and often appear to lead to confusion for our consumers.

Whilst I know I put forward the approach of sibling usage for pie-text-input, after working on pie-text-area where it is baked into the component template, I am no longer a fan of the original approach. It introduces extra styling work for the consumer in some situations.

I think on balance, despite me disliking prop-drilling, I'd go for baking the label into the component template and potentially utilising object property values to reduce the amount of props added.

This certainly isn't a strong preference!

[xander-marjoram]

Combining drilled props into a single prop is an interesting idea. I'm trying to think how we might define the types for these in a way that keeps things tidy...

[dandel10n]

The main disadvantage of prop drilling for me is the need to manually update the usage of child component in all the components it is used in in case its props changes.

Providing a dedicated slot with clear guidance of usage saves us from responsibility to keep children components in sync and gives consumers more freedom. We will never avoid misuse no matter which approach we choose. And from architectural point of view components that have a child component needs to be responsible only for styling the position of it and everything else comes from the child so why not to give consumers the ability to set all the needed props for children directly by passing them in slots.

[jamieomaguire]

I fully agree on the cons of prop drilling. Perhaps leveraging slots in a way that feels similar to native HTML is most appropriate.

[ashleynolan]

I tend to agree with @dandel10n – I think we should choose the 'best' solution in terms of maintenance and for the DS, rather than designing to protect from misuse (as that'll likely happen anyway).

Using parent props comes with too many overheads, especially for something like a label which will be used in many different components. I'd go for a slot, with good guidance in the docs on usage.