{"id":39205,"date":"2023-04-27T15:38:16","date_gmt":"2023-04-27T19:38:16","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=39205"},"modified":"2023-04-27T15:38:16","modified_gmt":"2023-04-27T19:38:16","slug":"apples-guidance-for-stateobject-initialization","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/04\/27\/apples-guidance-for-stateobject-initialization\/","title":{"rendered":"Apple’s Guidance for StateObject Initialization"},"content":{"rendered":"

Jordan Morgan<\/a> (Mastodon<\/a>):<\/p>\n

In an attempt to put an end to our StateObject<\/code> woes in a more paradigmatic manner, Luca Bernardi<\/a> let us know that Apple’s official documentation<\/a> now tackles the matter. Specifically, there is now text detailing how to handle dependency injection with StateObject<\/code>. This is exactly the kind of material we need from Apple, and it clears up a lot of confusion and advice I’ve been reading.<\/p>

[…]<\/p>

SwiftUI only will initialize a state object the first time<\/em> you call it within its view.<\/p>

[…]<\/p>

All of this basically boils down to - dependency injection with state object initialization works great if<\/em> parties outside of the view housing it are feeding it data that doesn’t change either.<\/p>

[…]<\/p>

If you did need the autoclosure to fire again, you could set the identity of the view to the value you’re interested in. […] Since the state object isn’t recreated when view inputs are changed (and it certainly shouldn’t), but when the view’s identity changes, this route forces the initializer to run again. But again, I can’t really see this being a viable route for most projects.<\/p><\/blockquote>\n

Previously:<\/p>\n