state with reference types #1157
Replies: 1 comment 1 reply
-
In general, I think we would advise against keeping reference types directly in state. It just introduces too many unknowns, like spooky action at a distance, and pain points, like manual equality operations that can get out of sync with the stored data, which view stores and SwiftUI heavily rely on for recomputing view state. Core Data poses a similar problem, and is why those intrepid enough to use TCA and Core Data together typically introduce a translation layer, where they will use the environment to fetch an object and then convert it to a value type before inserting it into state. For Core Data and other graph databases, the environment seems like a natural place to introduce a client, and then your app's reducers can query this database conditionally depending on the view. Then, any state the view needs can be converted into a value type. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The main readme and general usage describes to always use simple value types to build your app state.
I'm currently working on an app that has a graph like state (reference types) and would like to understand what I should look out for if I'd try to use TCA with that setup and if it's possible.
Part of my state looks somewhat like the following:
Is it possible to use reference types in TCA state as well? What should I look out for? I'm not sure how to approach it yet.
Beta Was this translation helpful? Give feedback.
All reactions