design-patterns - Reactjs Redux 我们应该为状态树中的每个对象创建子 reducer 吗？

Question

据我所知，redux 应用程序维护状态树的正确方法是对其进行规范化，尽可能展平数据并使用combinereducer 创建状态树的切片。

具有帖子和用户的示例应用程序

const rootReducer = combineReducers({
  user:userReducer,
  posts:postsReducer,
});
const store = createStore(rootReducer);

给定的帖子数组将所​​有帖子保持在初始化状态，State.posts 看起来像

let initialState =   {
    byId:{1:{id:1,title:'post1'}},
    ids:[1],
    meta_data:{unread:1,old:0}
    }

现在，如果我们有大约 10,000 个帖子，我们最终会得到 state.post.ids.length === 10000 这很好，

问题是。由于我们的reducer每次需要更新时都会返回一个新状态，例如我们需要将meta_data.unread更新为等于0，我们将返回一个新的 Post 对象。

return object.assign({},state,{meta_data:{unread:0,old:1}})

这将重新渲染使用 state.post 树的任何属性的所有选择器和组件!

which sound like a problem right ?** all we wanted is updating unread counter.. why recalculate all selectors and components of Posts ?

所以我有这样的想法，可能是state.posts也应该使用combineReducers来组成，以便每个attr。的帖子本身应该有一个 reducer 。

将 postsReducer 拆分为多个

postsMainReducer, ==> deal with adding or removing posts
postMeta_dataReducer, ==> deal with meta_data of posts
singlePostReducer ==> Now this is dynamic !! how can i create such ??

这是正确的吗？我添加的复杂性超出了需要？

-->有人能给我们看一张已经运行的企业应用程序状态树的图片吗？那么我们可以从中学习如何组织状态？

Answer 1

It’s important to note that a Redux store really only has a single reducer function. The store passes the current state and dispatched action to that one reducer function, and lets the reducer handle things appropriately.

Obviously, trying to handle every possible action in a single function does not scale well, simply in terms of function size and readability, so it makes sense to split the actual work into separate functions that can be called by the top-level reducer. In particular, the common suggested pattern is to have a separate sub-reducer function that is responsible for managing updates to a particular slice of state at a specific key. The combineReducers() that comes with Redux is one of the many possible ways to achieve this. It’s also highly suggested to keep your store state as flat and as normalized as possible. Ultimately, though, you are in charge of organizing your reducer logic any way you want.

However, even if you happen to have many different independent sub-reducers, and even have deeply nested state, reducer speed is unlikely to be a problem. JavaScript engines are capable of running a very large number of function calls per second, and most of your sub-reducers are probably just using a switch statement and returning the existing state by default in response to most actions.

If you actually are concerned about reducer performance, you can use a utility such as redux-ignore(https://github.com/omnidan/redux-ignore) or reduxr-scoped-reducer(https://github.com/chrisdavies/reduxr-scoped-reducer) to ensure that only certain reducers listen to specific actions. You can also use redux-log-slow-reducers(https://github.com/michaelcontento/redux-log-slow-reducers) to do some performance benchmarking.

以下是我最常引用的项目 -

这些是 Redux 的实际用途。

这里有一些链接:

https://github.com/andrewngu/sound-redux

https://github.com/echenley/react-news

https://github.com/paulhoughton/remember/

https://github.com/paulhoughton/mortgage/

https://github.com/benoitvallon/react-native-nw-react-calculator

https://github.com/jfurrow/flood

https://github.com/FH-Potsdam/shifted-maps

https://github.com/quirinpa/2post

https://github.com/karlguillotte/Ctfs

https://github.com/madou/gw2armory.com