Open utterances-bot opened 2 years ago
在实际业务快速迭代过程中,组件常出现大量重复性工作,少量个性化定制的需求,如果不遵循 DRY(Don't Repeat Yourself)的规则,会造成项目臃肿和难以维护的问题。但在许多情况下,无法对含有状态逻辑的组件进一步拆分。因此在没有 React Hooks 前,存在使用 HOC / Render Props 进行重构的方案。
“但在许多情况下,无法对含有状态逻辑的组件进一步拆分”这里指的是什么拆分方案?后面的“因此在没有React Hooks前”,与前面也是不相关的吧,这一段前面还没有提到React Hooks
我觉得可以这样改,可能更能表达这段本来想要表达的意思
在实际业务快速迭代过程中,组件常出现大量重复性工作,少量个性化定制的需求,如果不遵循 DRY(Don't Repeat Yourself)的规则,会造成项目臃肿和难以维护的问题。通常比较常见的方案是使用 HOC / Render Props 进行重构,然而这两种方案都无法对含有状态逻辑的组件进一步拆分。而React Hooks的出现,则很好地解决了这个痛点。
在实际业务快速迭代过程中,组件常出现大量重复性工作,少量个性化定制的需求,如果不遵循 DRY(Don't Repeat Yourself)的规则,会造成项目臃肿和难以维护的问题。通常比较常见的方案是使用 HOC / Render Props 进行重构,然而这两种方案都无法对含有状态逻辑的组件进一步拆分。而React Hooks的出现,则很好地解决了这个痛点。
我觉得这样改了之后,可能和文档要表达的意思依旧差了点——https://reactjs.org/docs/hooks-intro.html#its-hard-to-reuse-stateful-logic-between-components,首先,stateful logic包含了这些功能、状态、props等抽象概念在里面的,其次,原文档更多是为了表达这点——Hooks不会改变组件的层级,因而避免了使用HOC/render props时会引发的“嵌套地狱”,增强了可读性
所以可能这样改会更合适
在实际业务快速迭代过程中,组件常出现大量重复性工作,少量个性化定制的需求,如果不遵循 DRY(Don't Repeat Yourself)的规则,会造成项目臃肿和难以维护的问题。较早的方案是使用 HOC / Render Props 进行重构,然而这两种方案都会改变组件层级,形成“嵌套地狱”,使得代码的可读性下降。而React Hooks的出现,则很好地解决了这个痛点。
HOC vs Render Props vs Hooks | HZFE - 剑指前端 Offer
相关问题
https://febook.hzfe.org/awesome-interview/book2/frame-react-hoc-hooks