-
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
"Families" containers #184
Comments
I see 🤔 Interesting idea. As for a "stop all" mode, I am not sure I would support it in that same API, as that might open the door to potential mistakes where someone "forgets" to pass a group/tag/family prop and all stores that are supposed to be global suddenly become local. If we see a particular pain point being the case during testing, exporting a dedicated container (for instance called |
Family comes mostly from my background, aka Product Families - something together for any reason, and The problem here that I am not sure what I really need - I am trying to imagine use case for multiple tags and I can imagine a few theoretical ones (well, multiple expiration tags for cache is a thing, but store is not a resource), but no practical one. A good extension point we might never need. Speaking of "global" containers - currently, I have the following helper function to be used in tests in order to "check" isolation: window.getSweetstateGlobalStores = () => {
return [...defaultRegistry.stores.keys()].filter(name => name.includes('@__global__'));
} Then I can create snapshot tests to know which stores ended as global, or which states containing a magic keyword are global to make this check less sensitive to changes outside its responsibility. This is an important moment, as the ability to isolate something without the ability to check and verify is a foot gun 🔫. Probably with a little more love around this aspect we can mitigate all your worries about |
Fair, however that is only due to the lack of this sort of feature. You can still add that function to ensure long term isolation via a specific test, but you would not need to protect production code from it. (or am I missing something else?) Another thing we could add is an API like createGlobalContainer({ onInit: (store, otherInitialisedStores) => ... , onUpdate: (store, otherInitialisedStores) => }) where by receiving the store object as argument, you can decide what to do with it. It might be logging, might be dispatching actions, ... Sort of like a middleware, but instead of configuring it globally via the Also thinking more about it, I wonder if the tag/family container API should require the tag on creation and not at runtime. I feel having it as prop might create confusion and need for complex handling (like in case of dynamic tags). const experienceTag = createTag('my-experience')
const ExperienceContainer = createTagContainer(experienceTag, { onStoreInit, onStoreUpdate }); |
And speaking about |
Right, so maybe a better API is: const ExperienceContainer = createGlobalContainer({
capture: (StoreType) => StoreType.name.includes('experience-'),
onStoreInit: (storeInstance, otherInitialisedStores) => { ... },
onStoreUpdate: (storeInstance, otherInitialisedStores) => { ... },
}) Where |
Names are handy, but not always the right signal. One need tags to be free to tag some Ideally, it should be more explicitly configurable from the stores itself. Meaning |
The "global" nature of stores is a feature of sweetstate making it easy to use. It is also some sort of 🔫 footgun creating an opportunity for various issues to appear.
Containers for the rescue, but creating and more importantly using containers for all possible stores is a little complicated, potentially leading to a "wrong coupling" when a parent has to pull containers from different dependencies in order to apply them in a correct place.
I would like to prose an extension to the default
Container
primitive capable of acting as a boundary for multiple stores, a single Container many:BoundaryContainer
: emulatesdefaultRegistry
passing to the one above some stores scoping the rest inside selfdefaultRegistry
and pollute the global scope.Technical implementation
I can see multiple different ways of achieving desired functionality but would like to propose a
family
(or atag
) based one.Technically speaking, a single FamilyContainer will "unfold" into multiple "normal" ones. And obviously - it can be only a boundary with no life-time hooks present.
Extra requirements
With some stores now being able be "captured" at some point it might be handly to introduce stores which have to be captured. For example, one might demand that a store with configured family should have a dedicated Container to be used as store is "expected" to be isolated.
However, such a feature might be useful for other states as well and ideally should be configurable separately.
The text was updated successfully, but these errors were encountered: