The reason we’d want to do such a refactor is that putting the cancel and save hooks in the child view causes the view to be overly specified. Maybe we want to reuse that view in situations where the buttons have different labels, or different placement, or not visible at all. Supporting all of those use cases would mean we have to pass in all types of configuration data to describe exactly what kind of ItemView we want.

It would be far better if we just allowed whoever creates the ItemView to be responsible for attaching the action buttons, and then it would be free to use whatever labels or placement it wants.

Unfortunately this is not possible right now because the most up to date version of the item state lives only in the ItemView’s @State field. The outside simply does not have access to that data.

So, these 3 problems are substantial enough for us to want to find another way to manage this state. In order to facilitate communication between these two views we simply need to get rid of @State and reach for a tool that allows for 2-way communication.