Javascript Reactjs：类/原型在我们的应用程序中有位置吗？

一名O.O开发人员正在向模块世界过渡

我几乎所有的JavaScript编码经验都是在React中完成的，我构建的几乎所有东西都严格使用React组件、存储、操作和调度程序

除此之外，我试图抽象的所有内容都放在了助手模块中。（XUtils、YUtils-webaputils等）

---

我在哪里迷糊了

但是昨天我遇到了一个问题，它显示了我对React的理解存在差距，因为我发现自己想要创建一个帮助器类/原型（不管您如何封装代码）添加到组件，因为典型的导入模块只有方法，而我需要一些可以封装变量的东西。

感觉不太对，但我无法解释为什么我觉得自己无法将类/原型插入React代码的任何部分。

问题：

我们所有用于抽象/委托代码的助手类是否都应限于模块？如果是这样的话，您能否解释一下React编程为什么是一个模块世界背后的一些理念？

典型的导入模块只有方法，而我需要一些可以封装变量的东西

模块可以导出任何内容。这是故意的

export const someConstant = 4;
export class SomeClass {}
export function someFunction() {}

想在一个模块中保留一组变量，以便在一组其他模块之间共享它们吗？听起来像一个配置文件/存储，去吧。这是一个坚实的模式

要使用返回类实例的工厂函数创建模块吗？好主意，立体图案

要从模块导出类吗？这是React对其组件的建议。React明确鼓励使用这种模式，这通常是一种良好的做法。去做吧

我们所有用于抽象/委托代码的帮助器类是否都应限于模块

您可以将任何内容放入一个模块中，将其导出，然后将其导入另一个模块。这是一个很好的实践，因为它创建了封装并允许代码重用。但是，该代码是否应限于模块？这是个奇怪的问题

• 你的意思是你想抽象代码而不重用它吗？我不知道那是什么样子
• 你的意思是你想抽象代码并共享它，而不是将其作为一个模块？你是怎么分享的

将代码抽象到应用程序其余部分使用的模块中并不是一个限制。这是一种超级力量

你能解释一下为什么React编程是一个模块的世界吗

---

因为编程是一个模块的世界。模块为我们提供了代码重用和（面向对象编程的一个关键特性）。模块通过限制代码的范围和表面积来鼓励可测试性。经过测试的模块使开发人员对其结果充满信心。模块都是正面的。

将问题的50%以上加粗并不能帮助强调，这只会分散读者的注意力。我通常尝试加粗位置，以帮助读者浏览问题并快速了解问题的内容。不过你是对的，这个有点太多了。我希望我有一个荧光灯，哈哈