应用接入 【译】也许你不必使用 Redux
人们常常在正真需要 Redux 之前,就选择使用它。“如果不使用 Redux,我们的应用无法扩展怎么办?”应用接入 Redux 之后,开发者就开始头疼了。“为什
原文链接:You Might Not Need Redux 人们常常在正真需要 Redux 之前,就选择使用它。“如果不使用 Redux,我们的应用无法扩展怎么办?”应用接入 Redux 之后,开发者就开始头疼了。“为什么为了开发一个简单的功能需要创建 3 个文件?”为什么! 人们痛苦地抱怨 Redux, React, FP, 不可变数据和一些别的东西,但我理解他们。那些不需要一系列代码来更新应用状态的方法自然比使用 Redux 更为简单。这说的没错,设计上也是如此。 Redux 提供了一种权衡。它要求你: 无论是不是 React 应用,这些限制都不是创建一个应用所必须的。事实上,这些都是非常强的约束,在把它们加入应用之前,你应当慎重考虑。 你有没有一些好的理由来使用 Redux? 当然是有的。这些限制吸引我是因为它同时也能够使应用拥有以下的特性: 如果,你正在开发一个可扩展的终端、JavaScript 调试器,或是某些类型的应用,那么,Redux 也许值得一试。至少,它是值得考虑的。(顺便说一句,Elm 和 Om 并不是新技术。) 然而,如果你只是学习 React,那么,Redux 并不是你的首选。 与之相反,你该看看理解 React。当你有真正的需要或想玩一些新东西的时候,才去尝试 Redux。然而,就像你使用其他强限制的工具一样,谨慎地选择是否使用它。 如果,你觉得用 Redux 的方式编码有压力应用接入,那可能意味着你或你的伙伴对此太较真了。Redux 只是你工具箱中的一件工具,一种尝试。 最后,记住你可以将 Redux 的理念运用到你的应用中,但不使用 Redux。试想一下,一个拥有本地状态的 React 组件:
这是非常合理的。认真地说,它值得重复使用。 使用内部 State 无可厚非。 Redux 提供的权衡是通过增加中间环节来将“发生了什么”和“该如何变化”之间进行解耦。 这样做是不是总是正确的哪?不,这是一种权衡。 比如,我们可以从组件中将 reducer 抽出:
发现没有,我们不必运行 npm install 就能使用 Redux。酷! 状态组件能不能也这样做?可能不行。也就是说,除非你有打算从额外的中间环节中受益。在当前这个时代,想法才是关键。 Redux 库它本身只是一系列的助手将 reducers “挂载”到全局唯一的 store 对象上。你可以根据你的喜好来选择是尽可能少,或尽可能多得使用 Redux。 但是,如果你付出了一些,确保你同时也能获得一些回报。 译者注:如果你对本文感兴趣,你或许也会对这篇文章感兴趣。 (编辑:海南站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |