Greater-London-Authority / ldn-viz-tools

https://greater-london-authority.github.io/ldn-viz-tools/
1 stars 0 forks source link

Align the APIs of user input component props #406

Open PaulioRandall opened 1 month ago

PaulioRandall commented 1 month ago

Is your feature request related to a problem? Please describe.

Creating forms, especially schematic based forms, required passing and binding on props with the same semantics but different names, e.g. The value of a user input field (the value you pass to the server) is a different prop for <Input>, <Select>, & <Checkbox>.

A lack of consistency means creating forms is more difficult and requires the user dev to be aware of all the different names so they don't get caught out, e.g. <Select bind:value> will result in the selected option, rather than the selected value of that option (which is the one you submit the form with).

Describe the solution you'd like

Reorganize and align the APIs for each user input component so props that are semantically the same have the same name and format.

E.g. <Input>, <Select>, <Checkbox>, and all other input components could all be used via bind:value to get the selected value, usually a string, number, or boolean value.

E.g. <Select>, <RadioGroup>, <CheckboxGroup>, and other input components with multiple options could be standardized to something like:

interface InputOption {
    value: string
    label: string
    color: string
    hint: string
    hintLabel: string
    ....
}

I also think input and form components could become their own group in storybook to improve cohesion.

Describe alternatives you've considered

None.

jamesscottbrown commented 1 month ago

On the one hand, uniformity is good; on the other, so is remaining close to the basic web standards and APIs.

For checkbox HTML elements, it is the checked (not value) attribute that is a Boolean recording whether or not a checkbox is indicated. Arguably, checked is therefore the least surprising name for the prop of our checkbox components, and should be kept.

For the Select component, our use of justValue to refer to what is arguably just the value (and use of value to refer to something else) is arguably surprising. This arises from following the API of the svelte-select library, rather than the HTML standard, so arguably we should change this.