javascript - 使用react的上下文允许将子组件呈现为父/祖 parent /曾祖 parent ...反模式？

Question

我有一个概念证明，似乎可行，但是我的一部分想知道这是否真的是一个好主意，或者是否存在使用Redux或替代策略之类的更好的解决方案。

问题

基本上，我的整个应用程序都有一个基本的React组件，其中包含一堆您可能期望的典型组件，标题，菜单，页脚等。

在我的树的更深处（更远的地方），我有一个组件，如果可以在标头组件中安装新的菜单项，那就太棒了。标头组件当然位于我的应用程序的顶部，因此访问被拒绝。

那只是一个这样的例子，但这是一个我从多个角度都遇到问题的案例。

我的疯狂解决方案

我研究了使用React的上下文，以公开允许子组件声明其希望出现在标头中的任何其他元素的函数。

在研究了这个概念之后，我最终将其重构为一个非常通用的解决方案，该解决方案实质上是一个React Element消息传递系统。此解决方案包括三个部分。

1.提供者

单实例组件与Redux的Connect组件在很大程度上相同。实际上，她是接收和传递消息的引擎。她的基本结构（针对上下文）是：

class ElementInjectorProvider extends Component {
  childContextTypes: {

    // :: (namespace, [element]) -> void
    produceElements: PropTypes.func.isRequired,

    // :: (namespace, [element]) -> void
    removeElements: PropTypes.func.isRequired,

    // :: (listener, namespace, ([element]) -> void) -> void
    consumeElements: PropTypes.func.isRequired,

    // :: (listener) -> void
    stopConsumingElements: PropTypes.func.isRequired,

  }

  /* ... Implementation ... */
}

2.生产者

高阶组件。每个实例都可以通过 produceElements上下文项“产生”元素，为特定名称空间提供元素，然后通过 removeElements删除这些元素（如果卸载了组件）。

function ElementInjectorProducer(config) {
  const { namespace } = config;

  return function WrapComponent(WrappedComponent) {
    class ElementInjectorConsumerComponent {
      contextTypes = {
        produceElements: PropTypes.func.isRequired,
        removeElements: PropTypes.func.isRequired
      }

      /* ... Implementation ... */
    }

    return ElementInjectorProducerComponent;
  };
}

3.消费者

高阶组件。每个实例都配置为“监视”附加到给定名称空间的元素。它使用 consumeElements通过回调函数注册“开始”监听，并使用 stopConsumingElements注销消费。

function ElementInjectorConsumer(config) {
  const { namespace } = config;

  return function WrapComponent(WrappedComponent) {
    class ElementInjectorConsumerComponent {
      contextTypes = {
        consumeElements: PropTypes.func.isRequired,
        stopConsumingElements: PropTypes.func.isRequired
      }

      /* ... Implementation ... */
    }

    return ElementInjectorConsumerComponent;
  };
}

这是我打算做的事情的粗略概述。基本上，它是一个消息系统。也许可以进一步抽象。

我已经在玩Redux，猜猜Redux有什么用？所以我不禁感到，尽管这对我有用，但也许这不是一个好的设计，而且我无意中站在Redux的脚趾上或制作了一般的反模式。

我想我没有直接使用Redux的唯一原因是因为我在生产Elements，而不是简单的状态。我可以遵循创建元素描述符对象的方法，然后将其传递给Redux，但这本身很复杂。



有什么智慧的话吗？



更新1

关于上述内容的一些其他说明。

这使我可以在整个组件树上上下，甚至从左向右注入Elements。我知道大多数React Context示例都描述了从祖父母到孙子组件的数据注入。

另外，我希望以上实现可以使开发人员从任何有关上下文用法的知识中抽象出来。实际上，我很可能会使用这些HOFS创建针对用例的更明确的其他包装。

即

消费者实现：

<InjectableHeader />

生产者实现：

InjectIntoHeader(<FooButton />)(FooPage)

我认为这很明确，而且易于理解。我确实喜欢这样，我可以在最关心的地方创建按钮，这使我能够与同伴建立更牢固的关系。

我也认为redux流可能是正确的想法。感觉就像是我自己变得更加艰难-我忍不住认为这种技术可能有一些优点。

有什么理由这是个坏主意吗？



更新2

好的，我现在相信这是一个坏主意。我基本上打破了应用程序的可预测性，并且使单向数据模型提供的所有好处无效。

我仍然不相信使用Redux是这种情况下的最佳解决方案，并且我已经梦想了一个更明确的单向解决方案，该解决方案使用上面的一些概念，但是没有任何上下文魔术。

如果我认为可行，我将发布任何解决方案作为答案。否则，我将去Redux踢自己，以免自己早点听别人的话。



其他例子

以下是一些其他尝试使用多种技术解决相同问题的项目/想法：

https://joecritchley.svbtle.com/portals-in-reactjs

https://github.com/davidtheclark/react-displace

https://github.com/carlsverre/react-outlet

Answer 1

我关于何时使用redux / flux / reflux / anothingelseux以及何时使用上下文的想法：


-ux存储对于以横向方式存储组件之间共享的信息很有用。这通常是您的用例：在没有其他明显连接的组件之间相互通信，并且这些组件在树中彼此远离。
当您不知道孩子会在哪里或有多少需要他们时，上下文可以为孩子提供信息。例如，我为地图使用上下文，以在当前视口上向其子级提供信息。我不知道所有的孩子是否都会使用它，但是他们都有潜在的兴趣，他们不应该更改它。


在您的情况下，我想说的是-ux方法是他们要走的路，没有理由为什么您的包装器组件应该处理与它无关的逻辑，并且代码会变得晦涩难懂。想象一下，开发人员稍后进入您的代码，并看到您通过上下文收到了该代码。任何父母都可以发送它，因此他将需要检查它的发送位置。包装器组件也会发生同样的情况，如果相似的操作开始相乘，您将处理许多与该组件无关的方法和处理程序。

拥有一个带有动作和简化程序的商店可以区分您的情况，这将是最易读的处理方式。