请记住，React的目的是更好地耦合逻辑上应该耦合的东西。如果您正在设计一个复杂的“验证密码”方法，它应该耦合在哪里?

每次用户需要输入新密码时，你都需要用到它。这可能出现在注册屏幕、“忘记密码”屏幕、管理员“为其他用户重置密码”屏幕等。

但在这些情况下，它总是会绑定到某个文本输入域。这就是它们应该耦合的地方。

制作一个非常小的React组件，只包含一个输入字段和相关的验证逻辑。在所有可能需要密码输入的表单中输入该组件。

这本质上与为逻辑提供服务/工厂的结果相同，但您将其直接耦合到输入。因此，现在您永远不需要告诉该函数在哪里查找它的验证输入，因为它是永久地绑定在一起的。

请记住，React的目的是更好地耦合逻辑上应该耦合的东西。如果您正在设计一个复杂的“验证密码”方法，它应该耦合在哪里?

每次用户需要输入新密码时，你都需要用到它。这可能出现在注册屏幕、“忘记密码”屏幕、管理员“为其他用户重置密码”屏幕等。

但在这些情况下，它总是会绑定到某个文本输入域。这就是它们应该耦合的地方。

制作一个非常小的React组件，只包含一个输入字段和相关的验证逻辑。在所有可能需要密码输入的表单中输入该组件。

这本质上与为逻辑提供服务/工厂的结果相同，但您将其直接耦合到输入。因此，现在您永远不需要告诉该函数在哪里查找它的验证输入，因为它是永久地绑定在一起的。

Service并不局限于Angular，甚至在Angular2+中也是如此，

Service只是helper函数的集合…

有很多方法可以创建它们并在应用程序中重用它们……

1)它们可以都是从js文件导出的分离函数，如下所示:

export const firstFunction = () => {
   return "firstFunction";
}

export const secondFunction = () => {
   return "secondFunction";
}
//etc

2)我们也可以使用工厂方法，比如函数的集合…在ES6中，它可以是一个类而不是函数构造函数:

class myService {

  constructor() {
    this._data = null;
  }

  setMyService(data) {
    this._data = data;
  }

  getMyService() {
    return this._data;
  }

}

在这种情况下，你需要用new key创建一个实例…

const myServiceInstance = new myService();

同样，在这种情况下，每个实例都有自己的生命周期，所以如果你想跨界共享它要小心，在这种情况下，你应该只导出你想要的实例……

3)如果你的函数和utils不会被共享，你甚至可以把它们放在React组件中，在这种情况下，就像函数在React组件中一样…

class Greeting extends React.Component {
  getName() {
    return "Alireza Dezfoolian";
  }

  render() {
    return <h1>Hello, {this.getName()}</h1>;
  }
}

4)另一种你可以处理事情的方法，可以使用Redux，它是你的临时存储，所以如果你在你的React应用程序中有它，它可以帮助你使用许多getter setter函数…它就像一个大的存储，可以跟踪你的状态，并可以在你的组件之间共享它，所以可以摆脱我们在服务中使用的getter setter的许多痛苦……

做一个DRY代码总是好的，不要重复需要使用的东西来让代码可重用和可读，但不要试图在React应用中遵循Angular的方法，就像第4项提到的，使用Redux可以减少你对服务的需求，你可以限制在一些可重用的帮助函数上使用它们，比如第1项……

或者你可以将类继承“http”注入到React组件中

通过道具对象。

更新: ReactDOM。render(<ReactApp data={app} />， document.getElementById('root')); 简单地像这样编辑React组件ReactApp: 类ReactApp扩展了React。组件{ 状态= { 数据:“ ｝ 呈现(){ 回报( < div > {this.props.data.getData ()} < / div > ） ｝ ｝

同样的情况:在做了多个Angular项目后转向React，没有一个简单的方法通过DI提供服务似乎是一个缺失的部分(抛开服务的细节不谈)。

使用context和ES7装饰器，我们可以接近:

https://jaysoo.ca/2015/06/09/react-contexts-and-dependency-injection/

似乎这些家伙在不同的方向上更进一步:

http://blog.wolksoftware.com/dependency-injection-in-react-powered-inversifyjs

还是觉得有违常理。在承担一个主要的React项目后，将在6个月的时间内重新审视这个答案。

编辑:6个月后回来，有了更多的React经验。考虑一下逻辑的本质:

它是否(仅)绑定到UI?将其移动到组件中(已接受的答案)。 它(只)与国家管理有关吗?移动到一个坦克。 两者都有关系?移动到单独的文件，在组件中通过选择器和坦克消费。

有些人还使用hoc进行重用，但对我来说，以上几乎涵盖了所有用例。另外，考虑使用鸭子来扩展状态管理，以保持关注点的独立性和以状态ui为中心。

可以使用export关键字从包含必要方法的文件中使用函数。

让我举个例子。假设我们有一个名为someservices .ts的文件:

export const foo = (formId: string) => {
    // ... the code is omitted for the brevity
}


export const bar = (): Entity[] => [
    // ... the code is omitted for the brevity
]

export default {
    foo,
    bar,
}

然后我们可以像这样在组件中使用这个服务:

import {
    foo,
    bar,
} from './someService'

const InnerOrderModal: FC = observer(() => {
    const handleFormClick = (value: unknown, item: any) => {
    foo(item.key)
    bar()
    
    return <></>
}