Comments (4)
Eg. I have an app model as follows:
...
How to structure the state in react-sweet-state for that case?
So, assuming your entities are properly normalised, you can easily create sweet-state hooks with selectors that return tags (or users) for a task:
// task-store.js
const selector = (state, id) => state.byId[id];
const useTaskById = createHook(TaskStore, { selector });
// tags-store.js
const selector = (state, tagIds) => tagIds.map(tid => state.byId[tid]);
const useTagsByIds = createHook(TagsStore, { selector });
// view.js
const MyView = (taskId) => {
const [task] = useTaskById(taskId);
const [taskTags] = useTagsByIds(task.tags);
// ...
}
I remember flux and refluxjs libs going with this approach. When redux appeared devs liked it almost instantly because of single source of truth introduction (one store instead of multiple). How is your solution better?
The main difference with Flux & co is that hooks are now first class citizen (not only on this lib), while composing data via components, the only thing possible at the time redux was published, is painful.
Have you looked at the recently published hook API for redux? Just by using it, don't you feel that having a single store becomes almost irrelevant if not a complication? Hooks can be composed and memoized as selectors do, but they are way more powerful because you can combine any kind of input/hook/effect regardless of the implementation. You are no longer forced to store everything in Redux, you can combine local state, context state, GraphQL, Redux, ... via a common interface.
I partially agree that Hooks API is handy for that but I'm afraid it reduces possibility to cross-view memoize some selection results. Also if you want to test selectors you probably have to instantiate your component for that occasion since hooks are useless outside of it.
One of the main benefit of such store reparation is that selectors are now much simpler, most of the times you don't even need to use reselect
or memoize them as changes are already "targeted" and arguments memoized by default in sweet-state.
The fact that selector
is a option given on sweet-state hook/component creation is exactly to avoid instantiating components to test them. You test them as you do in Redux :)
I've never heard of React hooks suggesting modular store system? Can you link something for reference here?
https://reactjs.org/docs/hooks-faq.html#should-i-use-one-or-many-state-variables
from react-sweet-state.
Thanks for all the answers :) I'm already converted ;)
from react-sweet-state.
Well, may I ask why would you have a "big state object" in the first place? One of the core concepts of sweet-state is that you should have lots of small different stores that deal with single concerns. If you have different entities/models and UI states you should create several stores and compose them via Hooks API (as your linked article says).
You should no longer follow a redux-like way of structuring your store, you should already think as React hooks suggest, with a more modular store system.
from react-sweet-state.
Well, may I ask why would you have a "big state object" in the first place?
I can think of some aspects here:
Server-side rendering
Setting initial app state for rendering is a bit simpler)
Debugging
Redux dev tools let you serialize / deserialize whole app state - can be helpful for error reporting.
Querying
I understand multiple aspects being tackled by multiple stores in react-sweet-state. However I don't see an efficient way of selecting state which touches multiple aspects. Eg. I have an app model as follows:
- three kinds of entities: tasks, tags, users
- tasks can have multiple tags and users assigned
- I can edit users, tags, tasks separately
- I have to query tasks, users and tags to display one view in my app. On the other views I need to query only tasks or users or tags.
How to structure the state in react-sweet-state for that case? Extra questions:
- What if we add a blog-like feature where we have articles with single author and tagging shared with the tasks?
One of the core concepts of sweet-state is that you should have lots of small different stores that deal with single concerns.
I remember flux and refluxjs libs going with this approach. When redux appeared devs liked it almost instantly because of single source of truth introduction (one store instead of multiple). How is your solution better?
Why I cannot simply have separate branches in the single global state object for that? I assume we are talking about state that should be shared/global because of multiple views being interested in querying data from it.
If you have different entities/models and UI states you should create several stores and compose them via Hooks API (as your linked article says).
I partially agree that Hooks API is handy for that but I'm afraid it reduces possibility to cross-view memoize some selection results. Also if you want to test selectors you probably have to instantiate your component for that occasion since hooks are useless outside of it.
You should no longer follow a redux-like way of structuring your store, you should already think as React hooks suggest, with a more modular store system.
I've never heard of React hooks suggesting modular store system? Can you link something for reference here?
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
- "Families" containers HOT 7
- 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.