Usually wrapping an app action in an additional layer of framework indirection causes problems (and leads to a lot of wrapping/unwrapping boiler plate) so I'll be interested to hear how this idea pans out
This is by far the first ever "app-wide" usage of AppIntends that I ever saw. To be honest, this seems like the "thousands of micro services"-approach of the late 2010s in the web industry, but maybe I'm an old grumpy man that hated the transition from MVC to MVVM and now with SwiftUI back to MCV or MVI. I see advantages in having an intend per action like create, update, delete for me the question is, if you have a web service in the background with a repository to hold states (if it is not SwiftData) if this approach is still usable *hm*.
Nice video and an interesting approach. What do you think about encapsulate code for actions in a simple type and create global methods? Then you have all actions in one place and you can use it everywhere in your app.
Not a fan of that, as I see no advantage over AppIntents (expect for smaller code). Essentially you're saying to use one big ViewModel for the entire app, right?
@@FloWritesCode Oke. No, not exactly. The data would be in the view. But all methods for buttons or other actions are in a separated type that you can access from all views. And you pass the data that the method needs as parameters.
I'm planning to do that, yes. It's not on the Roadmap right now though, so I'd suggest watching someone else's video on the topic in the mean time (or just the WWDC talk from this year where they presented the StoreKit news).
So in this example, let's say you wanted to add the ability to update and delete food. Would you need separate AppIntents for those two actions? If so, having a single view model that encapsulates all that logic sounds better to me
Yes, exactly. You‘d need one AppIntent for each piece of logic in your app. Swift Macros might help automate that process, but it is some overhead for sure…
