Unlock This Episode
Our Free plan includes 1 subscriber-only episode of your choice, plus weekly updates from our newsletter.
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
@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.
We uncovered a crash in SwiftUI’s Binding initializer that can fail, and filed a feedback with Apple. We suggest other duplicate our feedback so that this bug is fixed as soon as possible.
The proposal that added property wrapper support to function and closure parameters, unlocking the ability to make binding transformations even more powerful.
The ability to break down applications into small domains that are understandable in isolation is a universal problem, and yet there is no default story for doing so in SwiftUI. We explore the problem space and solutions, in both vanilla SwiftUI and the Composable Architecture.