Confused about Lifetime management #25
Replies: 2 comments
-
Each atom caches its value and subscribes to dependent atoms. Lifetime is required to clear that cache and subscriptions. Lifetime also guarantees that the clients will not be able to subscribe to the destroyed model and silently restart its atoms. For models that contains only value-atoms lifetimes is redundant, but note that UniMob prefers to compute data rather than copy:
if clients live as long as the scene, then good option is to create one LifetimeController should not be injected via DI and in most cases must be stored in private field in class where that controller was created. |
Beta Was this translation helpful? Give feedback.
-
Thanks, this clarifies things. What I am kindof missing on the client side is the UniRx/UniTask set of extensions on the returned IDisposables (AddTo(this)) but that could easily be added on my side. |
Beta Was this translation helpful? Give feedback.
-
I want to organize code in such way:
now what is confusing to ma that both ViewModel class needs to implement ILifetimeScope and all the "clients" need to have access to a Lifetime also to be able to call Reaction and When. It makes sense to me that clients need Lifetime access so that when they go out of scope, their "connections" go out of scope also. I don't get why ViewModels needs to implement this interface tho.
It is also confusing to me what should be injected to the clients a Lifetime or LifetimeController. In general my clients live as long as the scene they are part of so I want them to share a Lifetimeinstance and not each have own.
Beta Was this translation helpful? Give feedback.
All reactions