如果你还在寻找像Angular这样的服务，你可以尝试react-rxbuilder库

您可以使用@Injectable来注册服务，然后您可以使用useService或CountService。在组件中使用服务

import { RxService, Injectable, useService } from "react-rxbuilder";

@Injectable()
export class CountService {
  static ins: CountService;

  count = 0;
  inc() {
    this.count++;
  }
}

export default function App() {
  const [s] = useService(CountService);
  return (
    <div className="App">
      <h1>{s.count}</h1>
      <button onClick={s.inc}>inc</button>
    </div>
  );
}

// Finally use `RxService` in your root component
render(<RxService>{() => <App />}</RxService>, document.getElementById("root"));

预防措施

取决于rxjs和typescript 不能在服务中使用箭头函数

我需要一些可以在多个组件间共享的格式化逻辑，而作为Angular开发人员，我自然也倾向于使用服务。

我通过将其放在一个单独的文件中来共享逻辑

function format(input) {
    //convert input to output
    return output;
}

module.exports = {
    format: format
};

然后把它作为一个模块导入

import formatter from '../services/formatter.service';

//then in component

    render() {

        return formatter.format(this.props.data);
    }

第一个答案没有反映当前的容器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服务只是一个对象，它交付了一组与上下文无关的方法时，问题就变得极其简单了。只是Angular的DI机制让它看起来更复杂。DI非常有用，因为它负责为您创建和维护实例，但您并不真正需要它。

考虑一个名为axios的流行AJAX库(你可能听说过):

import axios from "axios";
axios.post(...);

它不是一个服务吗?它提供了一组负责某些特定逻辑的方法，并且独立于主代码。

Your example case was about creating an isolated set of methods for validating your inputs (e.g. checking the password strength). Some suggested to put these methods inside the components which for me is clearly an anti-pattern. What if the validation involves making and processing XHR backend calls or doing complex calculations? Would you mix this logic with mouse click handlers and other UI specific stuff? Nonsense. The same with the container/HOC approach. Wrapping your component just for adding a method which will check whether the value has a digit in it? Come on.

我只需要创建一个名为ValidationService.js的新文件，并按照如下方式组织它:

const ValidationService = {
    firstValidationMethod: function(value) {
        //inspect the value
    },

    secondValidationMethod: function(value) {
        //inspect the value
    }
};

export default ValidationService;

然后在你的组件中:

import ValidationService from "./services/ValidationService.js";

...

//inside the component
yourInputChangeHandler(event) {

    if(!ValidationService.firstValidationMethod(event.target.value) {
        //show a validation warning
        return false;
    }
    //proceed
}

您可以在任何地方使用这项服务。如果验证规则改变了，你只需要关注ValidationService.js文件。

您可能需要一个依赖于其他服务的更复杂的服务。在这种情况下，您的服务文件可能返回一个类构造函数而不是一个静态对象，因此您可以在组件中自己创建该对象的实例。您还可以考虑实现一个简单的单例，以确保在整个应用程序中始终只有一个服务对象实例在使用。

可以使用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 <></>
}

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