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项……

我和你处境相同。在你提到的情况下，我将输入验证UI组件实现为一个React组件。

我同意验证逻辑本身的实现应该(必须)不耦合。因此，我会把它放在一个单独的JS模块中。

也就是说，对于不应该耦合的逻辑，在单独的文件中使用JS模块/类，并使用require/import将组件与“服务”解耦。

这允许独立地进行依赖注入和单元测试。

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

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

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

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

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

在React世界中，我们有两种类型的逻辑:有状态的和无状态的。现在，这是开始React时要掌握的主要概念。这里我们更新的状态应该是更新UI，而不是Angular对dom的直接更新。两种类型的逻辑是:

That do not depend on state changes, i.e. static logic which doesn't need to re-render something based on state changes. For such cases just create regular js files and import them like a library or helper methods If you have some code that depends on state and u need to resuse it then two options - hocs and the newer hooks. Hooks are a bit hard to wrap our heads around but basically they would force their parent to rerender if their internal state changes so any stateful logic can be defined and reused in different components, and each hook instance would have its own isolated scope.

理解状态和声明性组件需要一点思维转变，但可以在评论中随意提出后续问题

第一个答案没有反映当前的容器vs呈现者范式。

如果你需要做一些事情，比如验证密码，你可能会有一个函数来做这件事。你会把这个函数作为道具传递给你的可重用视图。

容器

因此，正确的方法是编写一个ValidatorContainer，它将该函数作为属性，并将表单包装在其中，将正确的道具传递给子对象。当涉及到视图时，验证器容器包装视图，视图使用容器逻辑。

验证可以在容器的属性中完成，但如果你使用第三方验证器，或任何简单的验证服务，你可以将该服务作为容器组件的属性，并在容器的方法中使用它。我已经为restful组件做过这样的操作，效果非常好。

供应商

如果需要进行更多的配置，则可以使用提供者/消费者模型。提供者是一种高级组件，它包装在顶层应用程序对象(您要挂载的对象)附近和下面的某个地方，并向上下文API提供它自己的一部分，或者在顶层配置的属性。然后，我将容器元素设置为使用上下文。

父/子上下文关系不必彼此接近，只是子上下文关系必须以某种方式继承。Redux以这种方式存储和React Router函数。我已经使用它为我的rest容器提供了一个根rest上下文(如果我没有提供自己的)。

(注意:上下文API在文档中被标记为实验性的，但我认为它不再是实验性的，考虑到使用它的是什么)。

//An example of a Provider component, takes a preconfigured restful.js //object and makes it available anywhere in the application export default class RestfulProvider extends React.Component { constructor(props){ super(props); if(!("restful" in props)){ throw Error("Restful service must be provided"); } } getChildContext(){ return { api: this.props.restful }; } render() { return this.props.children; } } RestfulProvider.childContextTypes = { api: React.PropTypes.object };

中间件

还有一种我还没有尝试过，但有人使用过的方法是将中间件与Redux结合使用。您可以在应用程序之外定义服务对象，或者至少在redux存储区之上定义服务对象。在存储创建过程中，将服务注入中间件，中间件处理影响该服务的任何操作。

通过这种方式，我可以将rest .js对象注入到中间件中，并将容器方法替换为独立的操作。我仍然需要一个容器组件来为表单视图层提供操作，但是connect()和mapDispatchToProps已经覆盖了我。

例如，新的v4 react-router-redux使用这种方法来影响历史记录的状态。

//Example middleware from react-router-redux //History is our service here and actions change it. import { CALL_HISTORY_METHOD } from './actions' /** * This middleware captures CALL_HISTORY_METHOD actions to redirect to the * provided history object. This will prevent these actions from reaching your * reducer or any middleware that comes after this one. */ export default function routerMiddleware(history) { return () => next => action => { if (action.type !== CALL_HISTORY_METHOD) { return next(action) } const { payload: { method, args } } = action history[method](...args) } }

同样的情况:在做了多个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为中心。