使用 React.Context 注入 UI 组件是个好主意吗？答案

【问题标题】：Is it a good idea to use React.Context to inject UI-Components?使用 React.Context 注入 UI 组件是个好主意吗？
【发布时间】：2021-06-16 00:29:34
【问题描述】：

我打算构建一个 react 组件库。反应组件是 UI 组件，但应该只实现特定的逻辑。我希望用户能够定义一组用于组成实际组件的原子（基本反应组件）。我的主要目标是使库独立于特定的 UI 组件库，如 MaterialUI、ChakraUI 等。

我的想法是使用 React.Context 来注入这样的组件：

// Button Atom
const Button: FC = ({ children }) => (<button>{children}</button>)

const atoms = { button: Button }
const AtomContext = createContext(atoms);

// "higher" component
const HigherComponent: FC = () => {
  const atoms = useContext(AtomContext)
  // Logic ...

  return (
    <atoms.button>click me</atoms.button>
  )
}

export default function App() {
  return (
    <AtomContext.Provider value={atoms}>
      <HigherComponent />
    </AtomContext.Provider>
  );
}

这解决了我的问题。但我不确定这是否是个好主意。有没有更好的方法来注入 UI 依赖项？我的方法可能有什么问题？

【问题讨论】：

标签： javascript reactjs typescript dependency-injection

【解决方案1】：

根据个人经验，这个问题可能会导致多个答案。

但总体而言，通过上下文传递组件的想法有点滥用该概念。

另外，创建一个可以通过package.json 导入的独立库或创建一个包含组件的文件夹并导入它们并没有带来太多好处。

如果您需要将一些特定的东西传递给您的组件，您可以像在那里一样拥有一个自定义提供程序，但就组件本身而言，使用上下文没有常识。

如果您的最终目标是使用自定义上下文挂钩来缩短组件的导入列表，并让它们像这样，我认为总体而言这是一个糟糕的权衡。

【讨论】：

是的，感觉就像是对这个概念的误用。这就是我提出问题的原因。您的意思是说，与将原子放在单独的库中并导入它们相比，您没有看到好处吗？我不明白这如何解决问题。如果我有一个包@maltesar/atoms 和我想要构建的实际库@maltesar/highercomponents，我不能从“外部”更改第二个库中的原子导入，对吧？
是的，与单独的库或仅包含原子和其他组件的文件夹相比，我没有看到太多好处。如果您希望这些组件可重用，那么制作分离库是一个很好的解决方案。至于第二个问题，如果我理解正确，您是否希望将所有组件都包含在 @maltesar/hightcomponents 中，并且只从上下文中使用它们而不是导入它们？
对，我希望能够将任何实现原子“接口”的包传递到@maltesar/hightcomponents 包中。（键入的）上下文允许我这样做。
好吧，在这种情况下，你可以按照你的计划去做。我仍然认为这不是使用上下文的正确方法，这就是为什么我们从包或简单的组件/原子文件夹（集合）中导入组件，而不是在上下文中传递它们并从上下文中获取它们。我知道它是输入的，你会得到必要的 linting 和检查，但如果它适合你，那就去吧:)
您知道更好的解决方案吗？我不能说我对上下文解决方案很满意。如何将@maltesar/atoms-a 或@maltesar/atoms-b 或任何其他原子包作为依赖注入@maltesar/hightcomponents？我应该为此提出一个新问题吗？你真的帮助我提高了实际问题。谢谢:)

【解决方案2】：

我刚刚阅读了这个article，关于使用反应上下文进行依赖注入。作者的观点是，将非反应依赖项注入组件的反应上下文是一种很好的做法。但是，我不确定这是否适用于注入一组特定的反应组件。因为，react 组件只不过是函数，我认为使用 react 上下文应该没问题。

【讨论】：