Form Revolution

[sebald]

Description

We have to go over the forms and unify their API!

New

• <CheckboxGroup> refa: <Checkbox> and <CheckboxGroup> #2016
• <RadioGroup> feat: Accessible <Radio> and <RadioGroup> #2029

---

Refactor

• Form components should have a common props
• Label should have only one variant
• For Checkbox und Radios don't use our Label component for <label> use Box ( <Box as="label" variant="checkbox.value"/>)
• Label feat: Refactor <Label> #1914
• HelpText (support error and description) feat: Intorduce <HelperText> for fields #1920
• TextField feat: <Field> -> <TextField> #1963
• NumberField feat: Introduce <NumberFields> #2056
• TextArea refa: Use <Field> in <TextArea>  #1964
• Checkbox refa: <Checkbox> (uses new styling) #2008
• Radio feat: Accessible <Radio> and <RadioGroup> #2029
• Select refa: <Select> #2048
• Slider feat(comp): Slider rewrite with react-aria and new styling #2034
• Switch refa: switch with new styling #2049
• FieldBase supports width from theme via prop feat: Add width prop to fields to control width #2070

Bugs

• TextField and TextArea don't support variant and size #2011

Delete

• ValidationMessage refa: Remove <ValidationMessage> #2052

API

• Make everything available under the "Field.<...>" API! Not doing this since Field.Select.Option is super long and weird to type. This doesn't make the usage of Marigold better.

Consequences

Easier to use forms in Marigold 🤞

[sebald]

@ti10le we could also change the import API like the following:

import { Field } from '@marigold/components';

<Field.Text/>
<Field.TextArea/>
<Field.Checkbox/>
<Field.Select/>

I could life with that 😅

[sebald]

What's the common API of Field Elements?

• name

• label

• description

• errorMessage

• disabled

• readonly

• required

• defaultValue

• error (boolean)

Plus the regular props that the form HTML element has

[ti10le]

This would be also good for me. Then we don't include the same things from field in every field component 😊 It would be clear that all of them a Field component.

[sebald]

Yes, exactly 😄 question is how we document this and structure it inside of @marigold/components.

Do we create a Field/Form folder and put everything there?

[ti10le]

I would create a folder for every component like now but dont show the Field component in docs or storybook. Only together with the other part. Not all inside Field i think 🤔

[sebald]

Might be confusing for imports

[ti10le]

Why? Not publishing the Field folder

[sebald]

Why? Not publishing the Field folder

@ti10le not sure what do you mean.

I think our project structure has to reflect export, otherwise you'll have a hard time finding things. This would also mean that if we separate stuff in the documentation (e.g. forms, layout, content, ...) this should be reflected in side the project.

[ti10le]

Ok I think the way you want to do this would be good for me, too 😊

[ti10le]

ℹ️ Note for later: Field.tsx and HelpText.tsx are not tested enough. Coverage is not 100%

[ti10le]

I would make only a <RadioGroup /> component. The most DS have only the Group. Because you should never use an Radio standalone.