Create UI: re-architect Approval Type to use v-model="ApprovalTypeObject"

Re: src/components/Restoration/ApprovalType.vue

Jonathan wrote:
> Rather than passing a prop and event for each form field, what do you think of passing the entire "ApprovalTypeShared" object? If we're separating concerns, the parent shouldn't have to know the fields contained within a shared component and should have to know when we add or remove a field inside the shared component.

Severin wrote:
> What do you mean, "passing the entire shared component object"?
> If you mean passing an object of properties instead of individual properties then I think sure, why not.
>
> The components here are:
> ```
> |
> + RestorationBusinessName.vue (step 1)
> |
> + ApprovalType.vue (this component, which is a shim to the shared component)
> |
> + ApprovalTypeShared.vue (actually ApprovalType but renamed in parent)
> ```
>
> The top parent doesn't handling any props or events for its child.
> The shim handled the store interactions and the props/events for its child.
> The bottom component does the UI work and doesn't (and shouldn't) know about the store stuff.
>
> How would you improve this?

Jonathan wrote:
> I would suggest that ApprovalTypeShared.vue *should* talk to the store. We pass ApprovalTypeShared a store location (so it can be reused anywhere) and ApprovalTypeShared gets its status from the store and mutates the store as the user interacts with it. ApprovalType.vue doesn't have to know anything about the inner workings of the ApprovalTypeShared. We're free to add and remove fields from ApprovalTypeShared without having to make changes to ApprovalType.vue.
>
> If you're uncomfortable with the idea of using the store, an alternative approach is to use v-model to set / get the ApprovalTypeShared object. Using v-model objects is a little tricky (as we've discussed previously), but it's another way of encapsulating the ApprovalTypeShared without having to set individual field propos and emit individual field updates.