Dynamically render form field in Create Dataset Form + Fields Validations

[g-saracca]

What this PR does / why we need it:

Dynamically renders all fields of each metadatablock in the dataset creation form and adds their respective validations.

This sub branch is a combination of two issues that are tightly related.

• Dynamically render Create Dataset Form fields based on the backend configuration #336
• Add validation library to validate fields from the Create Dataset Form #338

Both issues have their own pr's merged to this sub branch:

• Feature/336 dynamically render form fields #357
• Feature/338 form validation library #368

Which issue(s) this PR closes:

• Closes
  Dynamically render Create Dataset Form fields based on the backend configuration #336
  Add validation library to validate fields from the Create Dataset Form #338

Special notes for your reviewer:

Create Dataset Form Storybook

Suggestions on how to test this:

Step 1: Run the Development Environment

1. Execute npm i.
2. Navigate with cd packages/design-system && npm run build.
3. Return with cd ../../.
4. Ensure you have a .env file similar to .env.example, with the variable VITE_DATAVERSE_BACKEND_URL=http://localhost:8000.
5. Navigate with cd dev-env.
6. Start the environment using ./run-env.sh unstable.
7. To verify the environment, visit http://localhost:8000 and check your local Dataverse installation.

Step 2: Test the Create Dataset Form

• Log in, click the create dataset button and the form fields should be displayed successfully.
• Submit the form without filling any required field, every required field should show te required error feedback, and the form should focus and scroll to the first input with an error.
• Fill a date field with the wrong format, respective feedback error should be visible.
• Fill an integer field with the wrong format (e.g.: 23.5), respective feedback error should be visible.
• Fill a float field with the wrong format (e.g.: 'hi'), respective feedback error should be visible.
• Fill an email field with a wrong format (e.g.: 'test@'), respective feedback error should be visible.
• Fill a URL field with a wrong format (e.g.: 'bad://something'), respective feedback error should be visible.
• Submit the form filling al required fields with the correct format, a new dataset should be created.

Run unit and e2e tests and check they are all passing.

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

Yes.

Also I modified at spa level not design system level the styles for the checkbox group, I think if it is successful we could apply it to the design system directly in the future.
This checkbox group that allows to select multiple values is a temporary replacement of the select multiple not yet done.
Examples below: 👇👇

Is there a release notes update needed for this change?:

Additional documentation:

I have refactor some design system components:

• Accordion: refactor of props using already existen props from react-bootstrap.
• AccordionBody: able to receive bsPrefix and as props and extend html props attributes.
• AccordionHeader: able to receive onClick, bsPrefix and as props and extend html props attributes.
• AccordionItem: able to receive bsPrefix and as props and extend html props attributes.
• FormGroup: able to clone children but wrapped through fragments also.
• Some form elements so that they can forward a react ref and pass it to the input itself. This was necessary so that the form validation library could focus and scroll to the first item encountered with a validation error.

All tests were ok and add one more test to test the cloning through childrens wrapped in fragments.

[MellyGray]

Works great! 🎉

I left some comments for minor improvements. Also can you solve the merge conflicts?

[MellyGray]

Consider using floating labels to look for the inputs by their labels

[g-saracca]

This is only for composed fields, where for example in this case, 'Author' is the root 'label' lets say but is not actually a label.

[MellyGray]

Yes, I understand. That's why I was suggesting the use of Floating Labels because each input needs to have its own label. "Author" cannot be the label for four different inputs.

We can use floating labels to provide each input with its own label "Author name", "Author Affiliation", without significantly altering the UI, as these labels are floating.

[g-saracca]

Oh, I understand now what you mean, labels from composed fields groups may not be unique. Let discuss it with the team, great!

[MellyGray]

@GermanSaracca I think that change doesn't need to block this PR. I'll approve the PR, and you can discuss it with the team. If there is an action item, you can create an issue. Thanks!

[MellyGray]

All requested changes addressed except for the multiple fields labels. Take a look at my comment #369 (comment)

We can discuss this decision with the team

[MellyGray]

LGTM!

[ekraffmiller]

Looks good, merging!