Comments (7)
Names are handy, but not always the right signal. One need tags to be free to tag some experience-
states to be contained, and some other to be not. For example experience-global-cache-lookup
can be a global one.
Ideally, it should be more explicitly configurable from the stores itself. Meaning createGlobalContainer
+ little extension of state info
== 💘
from react-sweet-state.
I see 🤔 Interesting idea.
On the naming: what would you think if the feature is called grouping? Like createGroupContainer
and createStore({ group: 'bla' })
. Or do you think that it might convey a more "deep" integration in the meaning? I find family a bit of an obscure word. Or I quite like tag
, assuming we allow multiple to be set.
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 GlobalContainer
) is more explicit and we can easily add it to our own utils.
from react-sweet-state.
Family comes mostly from my background, aka Product Families - something together for any reason, and groups
from by point of view demand a better reason
causing 🤯
Tags
are more explicit here and come without any extra context or meaning - you are right; they seems to be better understood by a wider audience.
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 stop all
mode.
from react-sweet-state.
currently, I have the following helper function to be used in tests in order to "check" isolation...
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 middlewares.add
API.
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 });
from react-sweet-state.
createGlobalContainer
is probably how it all should work internally - a "Boundary" which can decide to pass or stop, and then it can be configured in multiple ways to act as one needs.
Technically - the API you've provided can be also used to wire-up connections between different stores without using React components where different stores can currently meet each other.
And speaking about createTagContainer
/createTag
- the main question is how to retrofit amendment into the current database with less pain. So it should be something not the far from the current concepts.
from react-sweet-state.
a "Boundary" which can decide to pass or stop, and then it can be configured in multiple ways to act as one needs.
Right, so maybe a better API is:
const ExperienceContainer = createGlobalContainer({
capture: (StoreType) => StoreType.name.includes('experience-'),
onStoreInit: (storeInstance, otherInitialisedStores) => { ... },
onStoreUpdate: (storeInstance, otherInitialisedStores) => { ... },
})
Where capture
(or filter
or ??) is the function that decides which stores should be "registered" by the container. And devs can decide to match stores using name patterns for instance. Just need all experience stores be named experience-bla
for instance.
from react-sweet-state.
This has been merged as part of the improved Store/Container API #198 .
Basically by using the new containedBy
attribute on store creation we can link multiple stores to the same container.
See docs. It will be available on v2.7.0+
from react-sweet-state.
Related Issues (20)
- The useHook with selector does not trigger rendering properly HOT 3
- [Documentation request] - Example with Next.js SSR
- Possibly incorrect type definition for `ActionThunk` HOT 2
- Incorrect selector behaviour with promises
- Input caret will jump to end of string when using store HOT 4
- better type/name for dispatched actions HOT 1
- Persistent global scoped stores HOT 2
- Ability to pass callback function during store creation for store initialisation and updates HOT 3
- Non global states HOT 4
- Container cleanup occurs after remounting, clearing state set by onInit HOT 1
- Hook mount/unmount time depends at number of hooks on page HOT 1
- New major HOT 2
- Move from .js to .ts HOT 1
- Uncaught TypeError: Cannot read properties of null (reading 'unsubscribe') HOT 6
- Unstable scheduling behavior
- Unexpected change in behaviour beween React 17 and 18 HOT 14
- Discussion: Should an error in onUpdate trigger the container's error boundary? HOT 3
- Using container on update hook causes React 16 errors to be printed HOT 5
- createActions helper HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from react-sweet-state.