一位O.O开发人员向模块世界过渡
我几乎所有的JavaScript编码经验都在React中，我构建的几乎所有东西都严格使用React Components、Stores、Actions和Dispatcher。
除此之外，我试图抽象掉的所有东西都放入了助手模块中。（XUtils、YUtils WebAPIUtils等）
我困惑的地方
但昨天我遇到了一个问题，这表明我对React的理解存在差距，因为我发现自己想要创建一个帮助类/原型（无论你喜欢如何封装代码）来添加到组件中，因为典型的导入模块只有方法，而我需要一些可以封装变量的东西
感觉不太好，但我无法解释为什么我觉得不能将类/原型插入React代码的任何部分
问题：
我们所有用于抽象/委托代码的助手类是否都应限于模块？如果是的话，你能解释一下为什么React编程是一个模块世界背后的哲学吗
典型的导入模块只有方法，而我需要一些可以封装变量的东西
模块可以导出任何东西。这是故意的。
export const someConstant = 4;
export class SomeClass {}
export function someFunction() {}
想在一个模块中保留一堆变量，以便在其他模块之间共享它们吗？听起来像一个配置文件/存储，去吧。这是一个坚实的模式。
想要创建一个带有返回类实例的工厂函数的模块吗？好主意，图案扎实。
想要从模块导出类吗？这就是React对其组件的建议。React明确鼓励使用这种模式，并且通常是一种良好的做法。去争取吧。
我们所有用于抽象/委托代码的帮助程序类都应该局限于模块吗？
您可以将任何放入一个模块中，导出它，然后将它导入另一个模块。这是一个很好的实践，因为它可以创建封装并允许代码重用。但是，这个代码是否应该被限制为模块？这是个奇怪的问题。
- 你的意思是你想抽象代码而不重用它吗？我不知道那是什么样子
- 你的意思是，你想抽象代码并共享它，而不是将其作为一个模块？你是如何分享的
将代码抽象到应用程序其余部分使用的模块中并不是的限制。这是一种超能力。
你能解释一下为什么React编程是一个模块世界背后的哲学吗？
因为编程是一个模块的世界。模块为我们提供了代码重用（DRY模式）和封装（面向对象编程的一个关键特性）。模块通过限制代码的范围和表面积来鼓励可测试性。经过测试的模块让开发人员对他们的复苏充满信心。模块都是正面的。