Here’s one weird #SwiftUI trick Apple DON'T want you to know:
If you present a confirmation dialogue from a swipeAction or contextMenu nothing will happen as the view is removed before the dialogue is presented. Annoying, but it makes sense.
Instead, delegate the confirmation to the environment. Now the Button isn't responsible for the presentation and you're left with a nice clean call site.
Here's my implementation with an example: https://gist.github.com/phillipcaudell/ecb32dc5a3915931d225a6cb8a67ac34
@mattiem right, because if the State is inside the Button it’ll be destroyed when the menu/swipe disappears, taking the dialogue with it.
@phill interesting! Thanks for sharing. I wish we didn’t need this but 🤷🏻.
I noticed the same for sheet and full screen presentations too where the sheet can’t be in the Menu, swipeAction, etc. Do you have similar implementations for that?
@alpennec The implementation is a bit more involved, but yes you can expand it to sheets and other things.
Basic gist: have a global router that populates the environment with a navigate action. Define an enum of your views along with some sort of view factory protocol (Routable). Then have a modifier somewhere responsible for presenting.
Bonus benefit is the view state is now 100% serialisable and restorable.
@phill that seems solid! Maybe too advanced for what I do but happy to see it can be done and that it works. Thanks for sharing!
@phill I guess this is instead of the button toggling some state that drives the presence of the dialog?