refactor(research): extract several components to simplify the form

[codisart]

…r an update

PR Checklist

• - Commit messages are descriptive, it will be used in our Release Notes

PR Type

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Developer experience (improves developer workflows for contributing to the project)

Description

What this PR does

This PR introduces several components to encapsulate fields of the research update form. This should allow easier futur changes but also easier identification of duplication for input fields between how to and research.

What happens next?

Thanks for the contribution! We try to make sure all PRs are reviewed ahead of our monthly maintainers call (first Monday of the month)

If the PR is working as intended it'll be merged and included in the next platform release, if not changes will be requested and re-reviewed once updated.

If you need more immediate feedback you can try reaching out on Discord in the Community Platform development channel.

[benfurber]

@codisart Really nice refactor here, thank you.

1. It's similar to the smaller howto form components so it would be great if you could rename, etc. to fit the conventions used there.
2. What unit testing could be these components have?
3. Are there any gaps in our cypress tests for the form behaviour you've been tidying up here?

[benfurber]

Also got some linting issues. Running yarn format should sort you out.

[codisart]

Thank you @benfurber

I have some questions about your remarks.

1. I see that the naming in the HowTo module is HowtoField<Component>
   Should I keep this naming scheme with ResearchField<Component> ? Does it make sense to have the Research prefix since it is redundant with the path of the file ?
   Should I try to have the same breakdown of components ?

2. Should we unit test theses components ? It seems that these are only coherents as the whole form.

3. I am not sure to understand your question. Could you reword it ?

[benfurber]

@codisart

Maybe ResearchField<Component> is overkill but makes the scope of the component clear and consistent with how we do it elsewhere.

Smaller is better than big, so the component responsibilites you've setup are a win, that said, if you can mirror a breakdown in components it might show us where more generic components could be used.

Seeing as you've been reading through these components, what they do, what their responsibilities are and what behaviour they have - what tests should cover it all?

[benfurber]

Hey @codisart, did my comments from the other week make sense?