Question

O.O开发人员将他转变为模块世界

我的几乎所有JavaScript编码经验都在React中，几乎所有我构建的都严格使用React Components，Stores，Actions和Dispatcher。

除此之外，我尝试抽象的所有内容都已放入辅助模块中。（XUtils，YUtils WebAPIUtils等）

我感到困惑的地方

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

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

问题：

我们所有的抽象/委托代码的助手类是否应仅限于模块？如果是这样，你能解释一下为什么React编程是一个模块世界背后的哲学吗？

Answer 1

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

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

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

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

想要创建一个带有返回类实例的工厂函数的模块吗？好主意，扎实的模式。

想要从模块导出类吗？这就是React推荐的组件。 React明确鼓励这种模式，并且通常是一种很好的做法。去吧。

我们所有的抽象/委托代码的助手类是否应仅限于模块？

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

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

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

因为编程是一个模块世界。模块为我们提供了代码重用（DRY pattern）和encapsulation（面向对象程序设计的一个关键特性）。模块通过限制代码的范围和表面区域来鼓励可测试性。经过测试的模块为开发人员提供了置信度。模块都有好处。