Colocating actions with corresponding state

[atlassian]

Colocating actions with corresponding state

[albertogasparin]

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

[cytrowski]

Thanks for all the answers :) I'm already converted ;)

[albertogasparin]

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.

[cytrowski]

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?