Form Revolution

[sebald]

Description

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

New

• [x] <CheckboxGroup> #2016
• [x] <RadioGroup> #2029

---

Refactor

• [x] Form components should have a common props
• [x] Label should have only one variant
• [x] For Checkbox und Radios don't use our Label component for <label> use Box ( <Box as="label" variant="checkbox.value"/>)
• [x] Label #1914
• [x] HelpText (support error and description) #1920
• [x] TextField #1963
• [x] NumberField #2056
• [x] TextArea #1964
• [x] Checkbox #2008
• [x] Radio #2029
• [x] Select #2048
• [x] Slider #2034
• [x] Switch #2049
• [x] FieldBase supports width from theme via prop #2070

Bugs

• [x] #2011

Delete

• [x] ValidationMessage #2052

API

• [x] 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.