【问题标题】:ReactJS local vs global state and implementing redux at a later timeReactJS 本地与全局状态并在以后实现 redux
【发布时间】:2017-02-14 18:26:36
【问题描述】:

所以我们在一个项目上大约有两个月的时间。这是我第一次管理代码编写者而不是自己编写代码。上周我一直在阅读他们的代码。原本应该是一个简单的 React 应用程序现在变成了意大利面条式的混乱。

我了解:redux 有助于管理全局状态。但这是否意味着所有按钮都应映射到全局“动作”?这似乎造成了散布在整个应用程序中的整个混乱的对象。我一直在问自己,当本地状态可以用于 90% 的应用程序时,为什么我们要为所有事情使用全局状态。这是让我心痛的代码:

let subitems = SidebarItems[state.type].sub_items;
Store.dispatch(SidebarSubItemHandler(item.action, subitems[0], null));

if(item.sub_items[subitems[0]].param) {
    browserHistory.push(`${item.sub_items[subitems[0]].path}/${item.sub_items[subitems[0]].param}`);
} else {
    browserHistory.push(item.sub_items[subitems[0]].path);
}

subItembuttons = Object.keys(this.props.subitems.sub_items).map(subitem => {
    let subItem = this.props.subitems.sub_items[subitem];
    return <li className={this.props.activeSubItem.action == subItem.action ? "bottom-bar-item active" : "bottom-bar-item"}
               onClick={e => this.props.onClickSubItem(e, subItem)}
               key={subItem.action} style={this.props.subitems.inlineStyles.mobileSubItemLI}>
        <a href="">{subItem.item}</a>
    </li>;
});

应用程序中充斥着各种各样的对象,例如映射到“动作”对象的对象。所以在这一点上,我们决定废弃整个项目并从头开始,但没有 redux。让我们尽量只使用本地状态。到时候,我们需要全局状态,只为那个东西实现它,而不是应用程序中的每一个动作。这有意义吗?

所以我想我的问题是:如果我们使用本地状态和基本 React 开发应用程序,我们是否会产生不可逆转的问题,从而阻止我们基于每个项目实施 redux?

【问题讨论】:

  • 我认为在示例代码 sn-p 中提供更多文件将有助于人们查看代码库中意大利面条代码的上下文。同时使用本地状态和全局状态并没有什么明显的错误。我认为展示更多代码将有助于了解编写该代码的开发人员没有遵循 React/Redux 架构的哪些概念或原则。
  • github.com/reactjs/redux/issues/1287 瞧,制造商本人的回答。 Redux 的一个很好的用例是当你想从你的 UI 组件中分离状态。混合状态和组件有时是不可避免的,但将它们混合起来会很快变得很脏

标签: javascript reactjs redux single-page-application react-redux


【解决方案1】:

引用 http://redux.js.org/docs/faq/OrganizingState.html#organizing-state-only-redux-state 的相关 Redux FAQ 条目:

使用本地组件状态很好。作为开发人员,您的工作是确定构成您的应用程序的状态类型以及每个状态应该存在的位置。找到适合您的平衡点,并坚持下去。

确定应将哪种数据放入 Redux 的一些常见经验法则:

  • 应用程序的其他部分是否关心这些数据?
  • 您是否需要能够根据这些原始数据创建进一步的派生数据?
  • 是否使用相同的数据来驱动多个组件? 能够将此状态恢复到给定的时间点(即时间旅行调试)对您有什么价值吗?
  • 您是否要缓存数据(即,如果它已经存在,则使用状态中的内容,而不是重新请求它)?

根据您的具体问题:如果您相当一致地使用“容器组件”模式,那么将那些“普通 React”容器换成 Redux 连接的容器应该相对简单。有关“容器/展示组件”模式的文章,请参阅 https://github.com/markerikson/react-redux-links/blob/master/react-component-patterns.md#component-categories

另外两个想法。首先,我最近与人合着了一篇讨论why you might want to use Redux in a React application 的文章。

第二:是的,那个代码看起来有点丑。我希望这些至少是来自代码库不同部分的三个不同的 sn-ps,而不是一个 sn-p,但这很难阅读。在可读性方面,重复使用“sub_items”和“subitems”似乎有点危险。

它看起来也没有遵循良好的 Redux 实践。例如,惯用的 Redux 代码几乎从不直接引用 store。相反,对dispatchgetState 的引用可以通过中间件获得,因此可以通过redux-thunkredux-saga 在动作创建者中使用。连接的组件也可以访问dispatch

总体而言:绝对欢迎您使用尽可能多或尽可能少的 Redux,以及尽可能多或尽可能少的本地组件状态。不过,我认为更大的问题是您的团队实际上对 Redux 的理解程度,以及他们如何尝试使用它。

【讨论】:

  • 如果我们将来将一个组件挂接到 redux 上,我们还能在那个组件的小事情上使用本地状态吗?
  • 当然。正如引用的常见问题解答条目所说,“使用本地组件状态很好”。
  • 希望你不介意我再问你一件事。我们目前已经设法通过 this.props 从最父组件向下传递 1 个对象 {handlers} 来完成所有全局任务。这似乎很容易!为什么人们会切换到 redux 而不是传递函数的处理程序对象?
  • 如果你只传递几个值,或者只传递几个级别,那不需要太多工作。但是,随着应用程序的增长,您通常最终会“需要”顶级组件来了解每个嵌套组件所需的每条数据,并且必须将 props 向下传递 许多 级别。 Redux 简化了这个过程,它允许任何组件准确地指定它需要从存储中获取哪些数据,以及它想要分派哪些操作。这意味着更好的性能、更简单的组件和更易读的代码。
  • 我只有两个对象,而不是传递独立的道具。数据和处理程序。所以我可以向数据对象添加尽可能多的道具,并且仍然只需要传递 2 件事。每次我尝试阅读 redux 教程时,我都觉得天哪,这太复杂了。
猜你喜欢
  • 2020-08-06
  • 2018-05-02
  • 1970-01-01
  • 2020-08-06
  • 2019-03-27
  • 1970-01-01
  • 2020-09-09
  • 2020-07-22
  • 2018-03-17
相关资源
最近更新 更多