Description
During prototyping, there is significant duplicate code for the forms despite sharing multiple child form components.
Explore ways to consolidate and optimize the architecture of the forms.
Recent WIP designs indicate there will be landing pages for each instrument so we will need a Read view (with edit CTA)
Technical Notes
Using Vue 3 + Pinia + Composition API, the forms are separate routes, some with query parameters.
In order to be able to isolate feature development for each route (i.e. fix one thing and breaking another), the Function section of form fields are duplicated across form routes with slight differences while the other sections of field sets are all shared between the form routes as child form components.
The form templates are very similar in that the majority of fields are identical. The complexity lies in the prepopulationg of form values based on user selection of an existing or starting instrument when choosing to Modify existing instrument or Start from template which are options of the What would you like to do? form field shared by all the forms.
The Existing instrument and Starting instrument fields of the their respective /update and /template forms are of type Lookup whose options are powered by the useInstrumentStore data store which manages state for instruments (a response object from an API call to MPIC's backend).
The expectation is that selecting an instrument in the Existing instrument and Starting instrument dropdowns will pre-populate the form with that instument's data.
Because the field What would you like to do? is at the top of each form, a blank state of the /update (Modify existing instrument) and /template (Start from template) forms is necessary. Then the user can select an instrument from the corresponding dropdown
There is likely an asynchronous way to accomplish all this wherein selection of an instrument asynchronously prepopulates the rest of the form's default values. Initial prototyping separated concerns for each form route (/update, /update/:slug, /template, /template/:slug, /launch) so a page reload occurs between selections of a different instrument.
Suggested explorations:
- See what can be extracted into composables.
- Would more granular stores be helpful in prepopulating form bindings?
- Can forms be de-duplicated between /update, /update/:slug, /template, /template/:slug?
- Can the Function part of the forms be a shared child component?
Acceptance Criteria
- Ideally an MR with proposed changes
- Documentation of suggested approaches
Required
- Unit/Integration tests?
- Documentation?
- Passed QA?