T360731
==Description
During prototyping, there is significant duplicate code for the forms despite sharing multiple child form components.
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.
Explore ways to consolidate and optimize the architecture of the forms.
[[ https://docs.google.com/presentation/d/13GvROaf1jF0-jy5I2tLWJBLE8iL7H8oS6N5qsDXU_Yg/edit#slide=id.p | 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 is a 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 [[ https://doc.wikimedia.org/codex/latest/components/demos/lookup.html | 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 [[ https://vuejs.org/guide/reusability/composables | 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?
==Artifacts & Resources
- [[ https://miro.com/app/board/uXjVMtGrgVc=/?moveToWidget=3458764579792923671&cot=14 | Architecture Diagram ]]
- [[ https://docs.google.com/document/d/1ShOnODmq_RnRWE2h4oHIxyrCUDSjdL2zqDfT3aHp_lo/edit#heading=h.dkwj61y6h2kw | Instrument Configurator Implementation Design Doc ]]
- [[ https://www.figma.com/file/DeYZ9XwYNqbT0NW2aL8GdM/T352903---Metrics-Platform---Control-Plane?type=design&node-id=432-14297&mode=design&t=J0YulBdr19TkbeLR-0 | Wireframes ]]