How to achieve parallel scopes?

[TamasBarta]

I was looking at this library, and I'm trying to understand its scopes. In my head, scopes are a sort of hierarchy of IoC containers, so it's not exactly a stack, because with a stack, you cannot have two simultaneous descendants of an element, so it doesn't relate to navigation very well for me.

This is how a stack behaves:

+-----------------+
| App scope       |
+-----------------+
| Screen 1 scope  |
+-----------------+
| Screen 2 scope  |
+-----------------+

Of course, I can pop "Screen 1 scope" before pushing "Screen 2 scope", not a big difference.

Here's how I found scopes working in other environments, like in a hierarchy:

+--------------------+
| App scope          |
+--------------------+
          |
          V
+--------------------+    +--------------------+
| Screen 1 scope     | -> | UI element 1 scope |
+--------------------+    +--------------------+
          |
          V
+--------------------+
| UI element 2 scope |
+--------------------+

In this latter version, UI elements can be loaded/displayed independently of each other, so the order of loading/unloading can be like:

• 1 loaded
• 2 loaded
• 1 unloaded
• 2 unloaded

and not only

• 1 loaded
• 2 loaded
• 2 unloaded
• 1 unloaded

as it is possible with a stack-like logic, that is push/pop.

My question is if it is possible to achieve independent parallel scopes with GetIt. Thanks!

[pchasco]

I have the same issue. I want to create a scope to pass into a method that runs asynchronously, and when the asynchronous method completes I want to dispose of any resources that were created in the scope. Because the order the Futures complete is not deterministic, the scopes will be disposed in the incorrect order.

[escamoteur]

Hi, sorry for not looking into this earlier, but I had some mental health problems the last half-year.

I think there is a misunderstanding on how to best use scopes. Indeed get_it scopes are not ideal if you want to bind them on complex UI routes.
From my understanding scopes should best be used to implement different states of your business logic that are triggered by your UI. Like "User logged in/out" or " created new shopping cart"

It would be helpful if you could elaborate a bit more about what you want to achieve.

[pchasco]

No worries. Nothing is more important than your health, and everyone deserves to take time off.

Unfortunately, I cannot remember what I was doing at the time that I chimed in on this issue. However, what I think would be useful would be to create scopes independent of other scopes. This is a common feature of most dependency injection frameworks available to other languages. SimpleInjector, a DI container for .NET offers a pretty good explanation:

https://docs.simpleinjector.org/en/latest/lifetimes.html

It is useful to be able to create an independent "scope" of the container, and any scoped services created in that scope will also be destroyed when the scope is destroyed. Scoped services are not shared between scopes, so if two scopes live at the same time request an instance of the same service, each scope receives an independent instance of the service.

This is especially useful in web applications because you may have tens to hundreds to thousands of requests executing simultaneously, and sharing instances of services between requests is begging for concurrency problems, and possibly even creates security concerns.

On the app side, such issues with concurrent users are not a thing, but it is still desirable to have scopes that can be torn down as a user closes a modal dialog, navigates to a new page, etc. Simply having a reliable way to compartmentalize areas of an application makes reasoning about an application easier, and does help to avoid some hard to find bugs.

[escamoteur]

what you can always do is create separate instances of get_it. Wouldn't that already solve that?
For my understanding scopes should be controlled more from the business logic than from the UI.

[pchasco]

Yes, I think that would work. It had not occurred to me that I could create separate instances, since GetIt is often referenced through the singleton.

[escamoteur]

The first question that I want to ask is why do you want a separate scope for every screen? I see scopes orthogonal to the widget tree most of the time. They should more relate to the states of your business logic like logged in/out, or a shopping cart was created or something like that. For scopes that should only live as long as a widget I recommend the watch_it companion package to get_it which has a pushScope function. Why do you want multiple parallel scopes that are not hirachical? Am 1. Sept. 2024, 21:05 +0100 schrieb malabuyocfritz1984 ***@***.***>:

…

Hi @escamoteur, I am new to getit and this probably is a noob question, apologies in advance but how do I create a new instance of getit per screen to make it behave like its a separate scope per screen? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>