You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As mentioned in the README, having many services offered by an app gets a bit intense. Because of how context works, it means we'd be looking at a lot of top-level nesting.
There is another possible option however - shared context.
Implementation Goal
The best APIs are designed for those who use them, not those who build them, so it's worth looking at how we might like to apply a single-provider service structure:
The simple benefit is that we can now throw in a heap of services without a nesting nightmare, but we could do that without many architectural changes, so why does the above proposal attempt to wrap everything in a single context? Because it allows us to get services talking to each other. Let's say you have a Data service that uses Auth info, and an Auth service that will make use of unauthorised processes in the Data service - this structure will allow us to do this.
More thoughts on the way on this one.
The text was updated successfully, but these errors were encountered:
As mentioned in the README, having many services offered by an app gets a bit intense. Because of how context works, it means we'd be looking at a lot of top-level nesting.
There is another possible option however - shared context.
Implementation Goal
The best APIs are designed for those who use them, not those who build them, so it's worth looking at how we might like to apply a single-provider service structure:
And if we wanted to, we should be able to expose services at various points in our app:
The smarter way to handle this would be as follows, but the above illustrates being able to expose many services with only a few providers well:
How do we accomplish this?
A single context seems to be the way...
Benefits
The simple benefit is that we can now throw in a heap of services without a nesting nightmare, but we could do that without many architectural changes, so why does the above proposal attempt to wrap everything in a single context? Because it allows us to get services talking to each other. Let's say you have a Data service that uses Auth info, and an Auth service that will make use of unauthorised processes in the Data service - this structure will allow us to do this.
More thoughts on the way on this one.
The text was updated successfully, but these errors were encountered: