HOC vs Render Props vs Hooks | HZFE - 剑指前端 Offer

[utterances-bot]

HOC vs Render Props vs Hooks | HZFE - 剑指前端 Offer

相关问题

https://febook.hzfe.org/awesome-interview/book2/frame-react-hoc-hooks

[SnorlaxYum]

在实际业务快速迭代过程中，组件常出现大量重复性工作，少量个性化定制的需求，如果不遵循 DRY（Don't Repeat Yourself）的规则，会造成项目臃肿和难以维护的问题。但在许多情况下，无法对含有状态逻辑的组件进一步拆分。因此在没有 React Hooks 前，存在使用 HOC / Render Props 进行重构的方案。

“但在许多情况下，无法对含有状态逻辑的组件进一步拆分”这里指的是什么拆分方案？后面的“因此在没有React Hooks前”，与前面也是不相关的吧，这一段前面还没有提到React Hooks

我觉得可以这样改，可能更能表达这段本来想要表达的意思

在实际业务快速迭代过程中，组件常出现大量重复性工作，少量个性化定制的需求，如果不遵循 DRY（Don't Repeat Yourself）的规则，会造成项目臃肿和难以维护的问题。通常比较常见的方案是使用 HOC / Render Props 进行重构，然而这两种方案都无法对含有状态逻辑的组件进一步拆分。而React Hooks的出现，则很好地解决了这个痛点。

[SnorlaxYum]

在实际业务快速迭代过程中，组件常出现大量重复性工作，少量个性化定制的需求，如果不遵循 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的出现，则很好地解决了这个痛点。