Implement selectboxes component edit form #52

sergei-maertens · 2023-11-14T16:22:35Z

No description provided.

* Added zod validation schema * Added base form layout (without options table & dynamic toggle) * Wired up edit form to storybook

All the components involved with managing the values for dropdowns/radios/selectboxes is now co-located closely together, and a composite component to display the relevant states is being set up.

The initial approach used the generic TextArea, but that leads to a horrible User Experience. Luckily enough we can re-use the JSONEdit component that was made for Laurens.

* Added zod validation schema * Added base form layout (without options table & dynamic toggle) * Wired up edit form to storybook

All the components involved with managing the values for dropdowns/radios/selectboxes is now co-located closely together, and a composite component to display the relevant states is being set up.

The initial approach used the generic TextArea, but that leads to a horrible User Experience. Luckily enough we can re-use the JSONEdit component that was made for Laurens.

…ms.dataSrc

component.values may temporarily be unset because the useLayoutEffect hook still needs to run, but state is already updating/components re-rendering which can still cause JS-level crashes.

It's re-used in the preview and default value, so we can avoid code duplication.

When options are added, changed, removed or re-ordered, the defaultValue configuration should reflect this. It may not include stale options, and for the sake of explicitness, every option that's present should be included with an explicit default value so that the form renderer has a reliable data structure to work with.

Setting the data source to 'manual' now populates the values with a single empty option.

We need to be a bit more generic than we'd like in our zod schema, but at least the UI is helping in preventing weird invalid input combinations. The schema is updated to ensure that validation runs, and a test is added that prevents empty values/options from being added to a component.

This component is to be used in the builder preview pane and to set the defaultValue for the SelectBoxes inside the builder edit form.

This was originally planned to use for the itemsExpression in the selectboxes component, but turned out to not be easy to manage to validate for valid JSON and eventually replaced with the already existing (courtesy of Laurens) JSONEdit component. Since we need to eventually implement the TextArea builder component anyway, it will be of good use later and was decided to keep it.

The ArrayField helper that is included in Formik can cause the errors array to contain 'undefined' when re-ordering items. This is unfortunately something outside of our control so it's best to just ignore this situation - knowing where it comes from lets me sleep at night.

This was an (unsuccesful) attempt to make userEvent.click(submitButton) actually submit the form(s) on Firefox, but it is bugged in testing library itself, see: testing-library/user-event#1075

Rather than setting the entire form field values state, it now allows setting a particular field value. This is required for the itemsExpression field in SelectBoxes component.

The filenames have been updated for consistency with other module names and the stories are now grouped under a folder 'values' since there will be more functionality added to values.

The selected mode determines the related inputs to configure the available options for a field with options.

Implemented as a minimal textarea which accepts (and sort-of validates) JSON input, this field will be used to enter the JsonLogic expression when values are to be retrieved dynamically from a variable.

The component manages the (form) state depending on the selected data source for field options/values and renders the appropriate dependent input: * manual -> use the values table so users can enter their options * variable -> use the JSON edit component to set the expression Additionally, it makes sure to clear the state of the 'other' field when a particular data source is selected, as the data model is essentially a discriminated union, which is then processed by the backend.

When manual values are available, they are rendered as is and their default value is taken into account. When the variable data source is specified, a single option is rendered to at least inform the form builder of the expression being used. In the future, we can possibly provide a 'variable' box so that they can try out the preview with a realistic form variable state.

The selectboxes now allows specifying the values, either manually or through an items expression. The labels of options can be translated on the translations tab.

When specifying values manually, the form builder enforces accessible practices in the value/label of each option. There are some limitations in the flexibility with zod validation unions and deep discriminators, but the UI currently prevents ending up in those edge case.