-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non global states #190
Comments
There is also another tangent to this: when there is an From another viewpoint, one can argue that detecting the existence of a container is possible by additional logic at |
That sounds interesting - distinguish global containers, local containers and container-less use cases. contained: undefined, // or 'global'
contained: 'local', // local scope-less container
contained: 'scope', // local any scoped container
contained: true // any container, including global Might be too much for one field, but this looks like a single property. Let's do the opposite and create 3 different options: // requires container with a scope
scoped: true, // false
// disallow global usage
global: false
// requires any container
contained: true All 3 makes a sense, but not simultaneously. |
Maybe something named However, I'm not a huge fun of blowing things up. If we proceed with #184 then it is quite simple to "log" things that end up being global but they should not. As said in the opening message, this behaviour can be implemented with tag + global container. const AppContainer = createGlobalContainer({
capture: (StoreType) => !StoreType.tag.startsWith('global'),
onStoreInit: (storeInstance, otherInitialisedStores) => {
// log exception and report store
},
}) But I understand this will be less "harsh" than the store self check as it will not catch places where defaultRegistry.onStoreInit((storeInstance, otherInitialisedStores) => {
// log exception and report store
}) That way we can directly look into the stores initialised in the global scope |
Proposed solution:
createStore(
initialState: {},
actions: { },
name: 'my-store',
behavior: 'contained', // cannot be global. Writing or reading to the global store will throw an error
behavior: 'global', // cannot be containerized. Explicitly global
behavior: undefined, // uncontrolled
})
// alternatively utilize single boolean
createStore(
initialState: {},
actions: { },
name: 'my-store',
isolated: true, // isolated
isolated: false, // global
isolated: undefined, // uncontrolled
});
- createLocalStore
- createGlobalStore
|
The main difference between SweetState and Context Provider is that the Context requires Provider to exists before Consumer. There is a case without Provider, in such case consumer will get the "default state" of context.
This creates a lot of friction but also resolves many problems by making information flow unidirectional.
Resolving similar problems in a similar way is something I hope #184 can give us. One day. But I would like to have some support right now.
I would like to introduce temporal mitigation of a problem global states might cause by introducing an extra flag to the
createStore
making it strict non-global in the dev environment and throw if a boundary container is missing.There is no other intention for this feature except support refactoring and create "screaming tests" when something which might blow up will blow up. There is no goal to break anything in production, as there could be still use cases missed by tests.
The text was updated successfully, but these errors were encountered: