您不需要了解“依赖注入”

我最近参加过一个前端职位的面试，其中一位同事问候选人：“您对依赖注入有什么了解？”。

我感觉这可能是一个“陷阱”问题，但当时还不太清楚为什么。 从那以后，我们花了一些时间讨论并用语言表达为什么这不是问前端开发人员的好问题。 我还将为在面试中遇到此问题的任何人提供一些建议。

那么，什么是依赖注入？

马丁·福勒（Martin Fowler）最初在他2004年的文章“ 控制容器的倒置和依赖注入模式 ”中创造了这一短语，以解释围绕Java社区中的控制倒置（IoC）概念发展的模式以及它如何适用于其他面向对象的环境。 归结为-尽可能允许模块所做的非核心操作可插入，而不是内部化（并因此紧密耦合）特定的实现。

这个概念是通过Angular引入前端的，Angular的创建者MiškoHevery在开放库时就在Google（主要是Java商店）工作。

这样一来，前端景观就好像野蛮人挥舞着jQuery和MooTools的混乱局面。 Angular像Alexander一样席卷了整个亚洲部落，带来了围绕“控制反转”和“依赖注入”的一系列讨论。

但是在前端开发的现代时代，所有框架都已将“组件化”作为解决复杂性问题的唯一解决方案，“依赖注入”现已成为标准的操作程序。

通过props传递的每个函数都是“依赖的注入”，每个声明用于处理事件或用户交互的prop的组件都在观察“控制权的倒置”。 借用的术语现在已因无处不在而过时了，也许还可以用作曾经在Angular统治下生活的JavaScripter的惯用语。

就是说，如果您要在面试室里找自己，面试官问您要说“依赖注入”，那么您可以说几件事，说明它与现代前端框架之间的关系，这至少可以引起您的注意。 -

“依赖注入有三种主要样式[…]如果您在当前有关控制反转的讨论中读到这些内容，您会听到这些分别称为类型1 IoC（接口注入），类型2 IoC（setter注入）和3型IoC（构造函数注入）。 我发现数字名称很难记住，这就是为什么我使用这里的名称的原因。 “ — 马丁·福勒

确实很难记住数字名称，但是在被问及有关依赖性注入的采访中，也许适量地撒上一些行话可能不是一个坏主意😉

让我们看一下这三种类型的类似物在React中的样子。

Type 3 IoC-构造函数注入

顾名思义，此组件将通过构造函数接收其依赖项。 这是这样的组件的外观：

class Knight extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      weapon: props.weapon
    };
  }
  render() {
    return `🐴 ${this.state.weapon}`;
  }
}

您将像这样使用它：

当然，通常应该直接使用该道具，而不是复制它。

2型IoC —二传手注射

代替在构造函数中设置依赖项，组件将具有可用的方法，这些方法可以在初始化后调用，并将依赖项作为参数传入。

class Knight extends React.Component {
  state = {};
  setWeapon = (weapon) => this.setState({ weapon });
  render() {
    return `🐴 ${this.state.weapon}`;
  }
}

用法：

componentDidMount () {
  this.knight.setWeapon(sword);
}
render () {
  return  this.knight = c} />;
}

同样，您几乎可以肯定不想这样做，而是直接通过prop传递依赖关系。

Type 1 IoC-接口注入

组件的道具是它与客户的接口，因此“必需的道具”将最接近于React的接口注入类比：

class Knight extends React.Component {
  static propTypes = {
    weapon: PropTypes.any.isRequired
  };
  render() {
    return `🐴 ${this.props.weapon}`;
  }
}

而您将其简单地用作

我希望这些示例能够说明依赖注入已变得多么普遍，并在主题出现时为您提供了一些要点。

Component + Props模式在构造上注入依赖关系，在初始化之后继续更新（设置）依赖关系，并且可以强制通过props接口传递依赖关系。 至少在React中，这三种模式合而为一。 （在现代Angular中，构造函数注入确实仍然很流行/不可避免）

也许围绕“渲染道具/作为孩子的功能”的讨论（例如，迈克尔·杰克逊的“ 使用渲染道具！ ”，多纳文·韦斯特的“ 作为子组件的功能是一种反模式 ”以及我自己的“ 解决高阶组件的问题…… ”）的讨论。 ）可以看作是此对话的扩展，其中甚至组件的渲染功能也是可以注入的依赖项。 诸如Downshift之类的图书馆将这一哲学概括为逻辑上的结论。 但是我怀疑这些文章和库的作者是否曾经需要关心这个特定术语。

谢谢阅读！

非常感谢Jeffrey Burt和Alex Wilmer的反馈和编辑笔记

您可以在Twitter @CheapSteak上找到我。

📬 订阅我的新闻通讯，以接收即将发表的文章的草稿。

本文由我的业余爱好项目npmcharts.com 赞助
比较随时间推移的npm软件包下载计数，以发现趋势，并查看使用和避免使用的软件包！

这是react-apollo和react-relay的交互式下载直方图

From: https://hackernoon.com/you-dont-need-to-know-dependency-injection-2e9d2ba1978a