React: createPortal：Reactツリーでのイベントの伝播を停止するオプションをサポート

また、mouseOver / Leaveの伝播はまったく予想外に見えます。

ポータルをボタンの外に移動できますか？

例えば

return [
  <div key="main">
    <p>Hello! This is first step.</p>
    <Button key="button" />
  </div>,
  <Portal key="portal" />
];

その後、ボタンを介してバブルしません。

それは私の最初の考えでしたが、！）そのようなコンポーネントコンテナにmouseEnterハンドラがあると想像してください。

unstable_rendersubtreeintocontainerでは、 ButtonWithPopoverコンポーネントのイベントとは何の関係もありません。mouseEnterは、マウスが実際にdivとボタンDOM要素に入ったときに機能し、マウスがポップオーバーの上にあるときに起動されません。 ポータルでは、ポップオーバーの上にマウスを置くとイベントが発生します。実際には、現時点ではdivを超えていません。 だから、私は伝播を停止する必要があります。 ButtonWithPopoverコンポーネントで実行すると、マウスがボタンの上にあるときにイベントの発生が中断されます。 ポップオーバーでそれを行い、このアプリケーションに一般的なポップオーバーコンポーネントを使用している場合、他のアプリパーツのロジックを壊すこともあります。

Reactツリーをバブリングする目的がよくわかりません。 ポータルコンポーネントからのイベントが必要な場合–単純に小道具を介してハンドラーを渡すことができます。 私たちはunstable_rendersubtreeintocontainerでそれを行い、それは完璧に機能しました。

反応ツリーの奥深くにあるボタンからモーダルウィンドウを開くと、モーダルで予期しないイベントが発生します。 stopPropagationもDOMでの伝播を停止し、実際に発生すると予想されるイベントを取得しません（

@gaearonこれは機能リクエストというよりはバグだと思います。 ポータル（以前はunstable_rendersubtreeintocontainerを使用していた）を介してバブリングするマウスイベントによって引き起こされる新しいバグがいくつかあります。 これらの一部は、マウスイベントをフィルタリングするための追加のdivレイヤーを使用しても修正できません。たとえば、ドラッグ可能なダイアログを実装するためにドキュメントまで伝播するmousemoveイベントに依存しているためです。

これが将来のリリースで対処される前に、これを回避する方法はありますか？

ポータルの現在のバブル動作は予想され、意図されているため、これは機能リクエストと呼ばれていると思います。 目標は、サブツリーが親の本当の子のように機能することです。

役立つのは、現在の実装では対応できない、または回避が難しいと思われる追加のユースケースまたは状況（表示されているものなど）です。

この動作が意図されていることは理解していますが、無効にできないことは重大なバグだと思います。

私の考えでは、DOMを操作するライブラリは、DOMの実装動作を壊さないように維持する必要があります。

例えば：

class Container extends React.Component {
  shouldComponentUpdate = () => false;
  render = () => (
    <div
      ref={this.props.containerRef}
      // Event propagation on this element not working
      onMouseEnter={() => { console.log('handle mouse enter'); }}
      onClick={() => { console.log('handle click'); }}
    />
  )
}

class Root extends React.PureComponent {
  state = { container: null };
  handleContainer = (container) => { this.setState({ container }); }

  render = () => (
    <div>
      <div
        // Event propagation on this element not working also
        onMouseEnter={() => { console.log('handle mouse enter'); }}
        onClick={() => { console.log('handle click'); }}
      >
        <Container containerRef={this.handleContainer} />
      </div>
      {this.state.container && ReactDOM.createPortal(
        <div>Portal</div>,
        this.state.container
      )}
    </div>
  );
}

DOMを使用する場合、DOM実装のようにイベントを受け取ることを期待しています。 私の例では、イベントはポータルを介して伝播され、そのDOMの親を回避します。これは、バグと見なすことができます。

人々は議論に感謝します、しかし私は何かがバグであるかどうかを議論することはそれほど役に立たないと思います。 代わりに、現在の動作では満たされないユースケースと例について議論する方が生産的であるため、現在の方法が将来の最善の方法であるかどうかをよりよく理解できます。

一般に、APIでさまざまなユースケースを処理し、他のユースケースを過度に制限しないようにします。 コアチームについて話すことはできませんが、構成可能にすることはおそらく解決策ではないと思います。 一般に、Reactは、構成可能なAPIよりも一貫したAPIを使用します。

また、この動作がDOMの動作方法ではないことも理解していますが、それ自体がそのようにすべきではないと言うのに十分な理由ではないと思います。 多くのreact-domの動作は、DOMの動作とは異なります。イベントは、ネイティブバージョンとはすでに異なる場合があります。 たとえば、 onChangeは、ネイティブの変更イベントとはまったく異なり、DOMとは異なり、すべての反応イベントはタイプに関係なくバブルします。

代わりに、現在の動作では満たされないユースケースと例について話し合う方が生産的です

React16への移行で壊れた2つの例を次に示します。

まず、ボタンで起動するドラッグ可能なダイアログがあります。 ポータルの使用に「フィルタリング」要素を追加しようとしました。これは、任意のマウス*キー*イベントでStopPropagationを呼び出します。 ただし、ドラッグ機能を実装するために、mousemoveイベントをドキュメントにバインドできることに依存しています。これは、ユーザーがマウスをかなりの速度で動かすと、カーソルがダイアログの境界を離れ、必要になるため、一般的です。より高いレベルでマウスの動きをキャプチャできるようにします。 これらのイベントをフィルタリングすると、この機能が機能しなくなります。 ただし、ポータルでは、マウスとキーのイベントがダイアログ内から起動したボタンまでバブリングしているため、さまざまな視覚効果が表示され、ダイアログが閉じられます。 ポータルを介して起動されるすべてのコンポーネントが10〜20のイベントハンドラーをバインドしてこのイベントの伝播を停止することを期待するのは現実的ではないと思います。

次に、一次マウスまたは二次マウスのクリックで起動できるポップアップコンテキストメニューがあります。 ライブラリの内部コンシューマーの1つには、このメニューを起動する要素にマウスハンドラーがアタッチされています。もちろん、メニューには、アイテムの選択を処理するためのクリックハンドラーもあります。 マウスダウン/マウスダウンイベントがメニューを起動するボタンに戻ってバブリングしているため、メニューはクリックするたびに再表示されます。

コアチームについて話すことはできませんが、構成可能にすることはおそらく解決策ではないと思います。 一般に、Reactは、構成可能なAPIよりも一貫したAPIを使用します。

この特定のケースでは、この立場を再考するようにあなた（およびチーム）にお願いします。 イベントのバブリングは、特定のユースケースでは興味深いと思います（ただし、手に負えないものは考えられません）。 しかし、それは他の人にとっては不自由になると思います、そしてそれはAPIに重大な矛盾をもたらします。 unstable_rendersubtreeintocontainerは決してスーパーサポートされていません

また、この動作がDOMの動作方法ではないことも理解していますが、それ自体がそのようにすべきではないと言うのに十分な理由ではないと思います。

ここから来ているのはわかりますが、この場合は（a）基本的な動作であり、（b）現在は回避策がないため、「DOMがこのように機能しない」というのは強い議​​論だと思います。完全に説得力のあるものではないにしても。

そして明確にするために：これをバグと見なすという私の要求は、ほとんどの場合、後でではなく早く修正のために優先されるようにするためのものです。

ポータルの私のメンタルモデルは、それがツリー内の同じ場所にあるかのように動作しますが、「オーバーフロー：非表示」などの問題を回避し、描画/レイアウト目的でのスクロールを回避することです。

ポータルなしでインラインで発生する同様の「ポップアップ」ソリューションは多数あります。 たとえば、すぐ隣のボックスを展開するボタン。

例として、GitHubの「Pickyourreaction」ダイアログを取り上げます。 これは、ボタンのすぐ隣にdivとして実装されています。 これで問題なく動作します。 ただし、別のz-indexが必要な場合、またはこれらのコメントを含むoverflow: scroll領域から持ち上げる場合は、DOMの位置を変更する必要があります。 イベントバブリングのような他のものも保存されない限り、その変更を行うのは安全ではありません。

「ポップアップ」または「ポップアウト」の両方のスタイルは合法です。 では、コンポーネントがレイアウトの外側に浮いているのではなく、レイアウト内でインラインになっている場合、同じ問題をどのように解決しますか？

私のために働いた回避策は、ポータルレンダリングの直下でstopPropagation呼び出すことです：

return createPortal(
      <div onClick={e => e.stopPropagation()}>{this.props.children}</div>,
      this.el
    )

ポータルを使用する単一の抽象化コンポーネントがあるので、これは私にとってはうまく機能します。そうでない場合は、すべてのcreatePortal呼び出しを修正する必要があります。

@methylこれは、ツリーのバブリングをブロックする必要があるすべてのイベントを知っていることを前提としています。 また、ドラッグ可能なダイアログで説明した場合、ドキュメントにバブルアップするにはmousemoveが必要ですが、レンダリングツリーをバブルアップする必要はありません。

「ポップアップ」または「ポップアウト」の両方のスタイルは合法です。 では、コンポーネントがレイアウトの外側に浮いているのではなく、レイアウト内でインラインになっている場合、同じ問題をどのように解決しますか？

@sebmarkbageこの質問が理にかなっているのか

ここでの問題のいくつかは、2つのメソッドが概念的に異なることをしているときにrenderSubtreeIntoContainerがcreatePortalに移植されているといういくつかのユースケースだと思います。 ポータルの概念は過負荷になっていたと思います。

モーダルダイアログの場合、モーダルがそれを開いたボタンの子のように動作することはほとんどありません。 トリガーコンポーネントは、 open状態を制御するため、レンダリングするだけです。 したがって、ボタンのcreatePortalがこれに適したツールではないと言うのではなく、ポータルの実装が間違っていると言うのは間違いだと思います。 この場合、モーダルはトリガーの子ではないため、あたかもそうであるかのようにレンダリングしないでください。 考えられる解決策の1つは、 renderSubtreeIntoContainerを使い続けることです。別のユーザーランドオプションは、モーダルのレンダリングを処理するアプリルートの近くにModalProvider配置し、（コンテキストを介して）レンダリングするメソッドを渡すことです。任意のモーダル要素はルートに必要です

renderSubtreeIntoContainerは、React 16のrenderまたはライフサイクルメソッドの内部から呼び出すことはできません。これにより、これまで説明してきたケース（実際、これを行うと、16）への移行が完全に失敗しました。 ポータルは公式の推奨事項です： https ：//reactjs.org/blog/2017/09/26/react-v16.0.html#breaking -changes

ポータルの概念が過負荷になってしまった可能性があることに同意します。 ただし、グローバルコンポーネントとそのコンテキストのソリューションが好きかどうかはわかりません。 これは、イベントがバブルスルーするかどうかを指定するcreatePortalのフラグによって簡単に解決できるようです。 これは、16以降とのAPIの互換性を維持するオプトインフラグになります。

ポータルのユースケースと、イベントの伝播を停止するオプションが必要な理由を明確にしようと思います。 ManyChatアプリでは、ポータルを使用して「レイヤー」を作成しています。 ポップオーバー、ドロップダウン、メニュー、モーダルなど、いくつかのタイプのコンポーネントで使用されるアプリ全体のレイヤーシステムがあります。 すべてのレイヤーは新しいレイヤーを公開できます。たとえば、メニューの2番目のレベルのボタンは、他のボタンがポップオーバーを開くことができるモーダルウィンドウをトリガーできます。 ほとんどの場合、レイヤーは、独自のタスクを解決するUXの新しいブランチです。 また、新しいレイヤーが開いている場合、ユーザーは下にある他のレイヤーではなく、この新しいレイヤーを操作する必要があります。 したがって、このシステムでは、レイヤーにレンダリングするための共通コンポーネントを作成しました。

class RenderToLayer extends Component {
  ...
  stop = e => e.stopPropagation()

  render() {
    const { open, layerClassName, useLayerForClickAway, render: renderLayer } = this.props

    if (!open) { return null }

    return createPortal(
      <div
        ref={this.handleLayer}
        style={useLayerForClickAway ? clickAwayStyle : null}
        className={layerClassName}
        onClick={this.stop}
        onContextMenu={this.stop}
        onDoubleClick={this.stop}
        onDrag={this.stop}
        onDragEnd={this.stop}
        onDragEnter={this.stop}
        onDragExit={this.stop}
        onDragLeave={this.stop}
        onDragOver={this.stop}
        onDragStart={this.stop}
        onDrop={this.stop}
        onMouseDown={this.stop}
        onMouseEnter={this.stop}
        onMouseLeave={this.stop}
        onMouseMove={this.stop}
        onMouseOver={this.stop}
        onMouseOut={this.stop}
        onMouseUp={this.stop}

        onKeyDown={this.stop}
        onKeyPress={this.stop}
        onKeyUp={this.stop}

        onFocus={this.stop}
        onBlur={this.stop}

        onChange={this.stop}
        onInput={this.stop}
        onInvalid={this.stop}
        onSubmit={this.stop}
      >
        {renderLayer()}
      </div>, document.body)
  }
  ...
}

このコンポーネントは、Reactドキュメントからのすべてのイベントタイプの伝播を停止し、React16に更新できるようにしました。

これはポータルに関連付ける必要がありますか？ ポータルをサンドボックス化するのではなく、（たとえば） <React.Sandbox>...</React.Sandbox>だけがあった場合はどうなりますか？

それでも私には不必要に複雑に思えます。 オプションのブールフラグをcreatePortalに追加して、バブリング動作をブロックできるようにしないのはなぜですか？

@gaearonこれは、私たちの特定のスライスにとってはかなり不幸な状況です-あなたまたはあなたにとって

私の現在の考えは、両方のユースケースをサポートする必要があるということです。 現在の親からサブツリーに流れるコンテキストが必要であるが、そのサブツリーがDOMの観点から論理的な子として機能しないようにする必要があるユースケースが実際にあります。 複雑なモーダルが最良の例です。モーダルウィンドウのフォームからのイベントがトリガーボタンまで伝播することはほとんどありませんが、コンテキスト（i18n、テーマなど）を渡す必要があります。

そのユースケースは、イベントの伝播が何にも影響を与えないようにcreatePortalを介してレンダリングされる、アプリルートに近いModalProviderでほとんど解決できると言えますが、それは回避策のように感じ始めます。うまく設計されたアーキテクチャ。 また、ライブラリが提供するモーダルは、自己完結型ではなくなったため、ユーザーにとってより煩わしいものになります。

APIの観点から追加します。 createPortalが両方を実行する必要はないと思います。モーダルケースでは、明確なツリーにかなり近いため、 ReactDOM.render （古いskool）を使用したいと考えています。そのコンテキストの伝播はしばしば必要です

@ kib357が投稿した回避策を使用した結果、外部アプリケーションのフォーカス管理コードの診断が非常に難しいバグを修正する

具体的には、合成フォーカスイベントでstopPropagationを呼び出して、ポータルからのバブリングを防止すると、＃documentのReactのキャプチャされたハンドラーのネイティブフォーカスイベントでもstopPropagationが呼び出されます。つまり、 <body>別のキャプチャされたハンドラーには到達しません

ポータルでの新しいバブリング動作は、私にとっては少数派のケースのように感じます。 その意見か真実か、私たちはこの問題についていくらかの牽引力を得ることができますか？ たぶん@gaearon？ それは生後4ヶ月で、本当の痛みを引き起こしています。 これは、完全に安全な回避策がないReact 16でのAPIの重大な変更であるため、バグとしてかなり説明できると思います。

@craigkovatchインラインの例をどのように解決するのか、まだ興味があります。 ポップアップがボックスのサイズを押し下げているとしましょう。 何かをインライン化することは、そのサイズを考慮してレイアウト内で何かを押し下げるため、重要です。 ただホバーすることはできません。

ポップオーバーを測定し、同じサイズの空白のプレースホルダーを挿入して上に揃えようとする可能性がありますが、それは人々が行うことではありません。

では、ポップオーバーがボタンのすぐ横など、コンテンツを所定の位置に展開する必要がある場合、どのように解決しますか？ そこで機能するパターンはどちらの場合でも機能すると思われるので、1つのパターンをお勧めします。

一般的に、これは両方のシナリオで機能するパターンだと思います。

class Foo extends React.Component {
  state = {
    highlight: false,
    showFlyout: false,
  };

  mouseEnter() {
    this.setState({ highlight: true });
  }

  mouseLeave() {
    this.setState({ highlight: false });
  }

  showFlyout() {
    this.setState({ showFlyout: true });
  }

  hideFlyout() {
    this.setState({ showFlyout: false });
  }

  render() {
    return <>
      <div onMouseEnter={this.mouseEnter} onMouseLeave={this.mouseLeave} className={this.state.highlight ? 'highlight' : null}>
        Hello
        <Button onClick={this.showFlyout} />
      </div>
      {this.state.showFlyout ? <Flyout onHide={this.hideFlyout} /> : null}
    </>;
  }
}

Flyoutがポータルの場合、それは機能し、ポータルにカーソルを合わせたときにイベントの上にマウスを置くことはありません。 しかし、もっと重要なことは、ポータルではなく、インラインフライアウトである必要がある場合にも機能することです。 stopPropagationは必要ありません。

では、ユースケースで機能しないこのパターンについてはどうでしょうか。

@sebmarkbageは、ポータルをまったく異なる方法で使用しており、 <body>の最後の子としてマウントされたコンテナーにレンダリングします。このコンテナーは、場合によってはz-indexを使用して配置されます。 Reactのドキュメントは、これが設計意図に近いことを示唆しています。 つまり、DOM内のまったく異なる場所にレンダリングします。 私たちのユースケースは、このスレッドに属する議論に十分似ているようには思えません。 しかし、一緒にブレインストーミング/トラブルシューティングを行いたい場合は、別のフォーラムでさらに話し合うことができれば幸いです。

私のユースケースは両方ではありません。 時には一方、時には他方。 それが関連性がある理由です。

<Flyout />は、ボディの最後の子にレンダリングするかどうかを選択できますが、ポータル自体を、ホバーされたコンポーネントの子ではなく、ホバーされたコンポーネントの兄弟に持ち上げる限り、シナリオは機能します。

それが不便で、深くネストされたコンポーネントから物事をテレポートする方法が必要なというもっともらしいシナリオがあると思いますが、そのシナリオでは、コンテキストが中間点からのコンテキストであることにおそらく問題はありません。 しかし、私はそれらを2つの別々の問題と考えています。

そのためにスロットAPIが必要かもしれません。

class Foo extends React.Component {
  state = {
    showFlyout: false,
  };

  showFlyout() {
    this.setState({ showFlyout: true });
  }

  hideFlyout() {
    this.setState({ showFlyout: false });
  }

  render() {
    return <>
      Hello
      <Button onClick={this.showFlyout} />
      <SlotContent name="flyout">
        {this.state.showFlyout ? <Flyout onHide={this.hideFlyout} /> : null}
      </SlotContent>
    </>;
  }
}

class Bar extends React.Component {
  state = {
    highlight: false,
  };

  mouseEnter() {
    this.setState({ highlight: true });
  }

  mouseLeave() {
    this.setState({ highlight: false });
  }

  render() {
    return <>
      <div onMouseEnter={this.mouseEnter} onMouseLeave={this.mouseLeave} className={this.state.highlight ? 'highlight' : null}>
        <SomeContext>
          <DeepComponent />
        </SomeContext>
      </div>
      <Slot name="flyout" />
    </>;
  }
}

ポータルは、DeepComponentではなくBarのコンテキストを取得します。 コンテキストとイベントのバブリングは、引き続き同じツリーパスを共有します。

@sebmarkbageモーダルケースは通常、レンダリングされた時点からのコンテキストを必要とします。 それは私が思うケースの少しユニークです、コンポーネントはそれをレンダリングしたものの論理的な子ですが、構造的なものではありません（より良い言葉がないため）、例えばあなたは通常フォームコンテキスト（リレー、formik、reduxフォーム）のようなものが欲しいです、何でも）通過するDOMイベントではありません。 また、そのようなモーダルは、トリガーの隣で、ツリーのかなり深いところにレンダリングされるため、構造的にそこに属しているという理由よりも、コンポーネント化と再利用が可能です。

このケースは、createPortalが提供するフライアウト/ドロップダウンのケースとは一般的に異なると思います。 Tbcポータルのバブリング動作は良いと思いますが、モーダルには適していません。 また、これはContextとある種のModalProviderでかなりうまく処理できると思いますが、それは特にライブラリにとってはちょっと面倒です。

ポータル自体を、ホバーされたコンポーネントの子ではなく、ホバーされたコンポーネントの兄弟に持ち上げる限り、シナリオは機能します。

私がフォローするかどうかわからない。 たとえば、keyDownイベントが予期しないDOMツリーをバブリングするという問題がまだあります。

@jquense私の例では、スロットはまだBarコンポーネント内にあるため、 <Form><Bar /></Form>ようなフォームからコンテキストを取得することに注意してください。

ポータルがドキュメント本文にレンダリングされた場合でも。

つまり、2つの間接（ポータル）のようなものです。深い->バーの兄弟->ドキュメントの本文です。

したがって、ポータルのコンテキストは依然としてフォームのコンテキストであり、イベントバブリングチェーンも同様ですが、どちらもホバーされたもののコンテキストではありません。

はい、申し訳ありませんが、それを見逃しました😳私がそれを正しく読んでいるなら、あなたはまだ<Slot>泡立っているでしょう？ モーダルダイアログの場合、おそらくバブリングは必要ないと思いますが、それは間違いなく優れています。 スクリーンリーダーの観点から考えるのと同じように、モーダルの外側のすべてを、アップしている間は反転させたいと考えています。 わかりません。その場合、バブリングは落とし穴だと思います。ダイアログ内のクリックがどこでもバブリングすることは誰も期待していません。

ここでの問題はポータルではないかもしれませんが、ツリー間でコンテキストを共有するための良い方法はありませんか？ 文脈からの一部ReactDOM.renderはモーダルには本当に問題なく、とにかくそれについてのより「正しい」考え方かもしれません...

ここでの私の考えは、それがまだモーダルからdiv、ボディ、ドキュメント、ウィンドウに至るため、多少のバブリングがあるということです。 そして、概念的には、フレームを超えて、収容ウィンドウなどに到達します。

これは、ARTやGLでレンダリングされたコンテンツ（およびある程度React Native）のように、これらのセマンティクスを取得するための既存のバッキングツリーがない可能性がある場合には理論的ではありません。 したがって、これがバブルの場所であると言う方法が必要です。

一部のアプリでは、モーダルにモーダルがあります。 たとえば、FBには、モーダルの上にある可能性のあるチャットウィンドウがあるか、モーダルがチャットウィンドウの一部である可能性があります。 したがって、モーダルでさえ、ツリーのどこに属するかに関して何らかのコンテキストがあります。 完全にスタンドアロンになることはありません。

だからといって、イベントのバブリングとコンテキストに2つの異なるセマンティクスを設定できないわけではありません。 それは両方ともこれについて明白であり、あなたは他なしで一方をポータル化することができます。

両方が同じパスをたどることを保証することは、ブラウザと同じようにユーザースペースイベントに対してイベントバブリングを完全に実装できることを意味するため、非常に強力です。

たとえば、これは今日のさまざまなReduxコンテキストで発生します。 this.context.dispatch("Hover")がユーザースペースイベントのバブリングであると想像してください。 コンテキストの一部としてReactイベントを実装することもできます。 私がこれを同じように使うことができると考えるのは理にかなっています、そして今、あらゆる方法であなたはそうすることができます。 これらの2つのコンテキストをフォークした場合、通常のコンテキストと並行してDOM構造に従う別のユーザースペースコンテキストAPIが作成される可能性があります。

だから、私はスロットのことで十分かどうかを確認するために少しプッシュしているのです。a）とにかくどのコンテキストバブリングが発生するかを明示する必要があるからです。 b）世界をフォークし、2つのコンテキストシステム全体を持つことを回避できます。

具体的には、合成フォーカスイベントでstopPropagationを呼び出して、ポータルからのバブリングを防止すると、＃document上のReactのキャプチャされたハンドラーのネイティブフォーカスイベントでもstopPropagationが呼び出されます。つまり、上の別のキャプチャされたハンドラーには到達しませんでした。

。 ハンドラーを#documentに移動することで修正しましたが、Reactのつま先を踏まないように、これまでは特に回避していました。

@craigkovatch 、onFocusCaptureイベントを使用しましたか？ 私の回避策では、キャプチャされたイベントを停止するべきではありません。 それがどのようであったか、そしてあなたがあなたの問題を解決するために何をしたかについてのより詳細な例を提供できますか？
また、私のコードにはblurイベントの停止に問題があると思います-停止すべきではありません。 それで、私はこの質問をより深く調査し、より信頼できる解決策を見つけようとします。

@ kib357回避策に問題があることを示唆しているわけではありませんが、Reactには別のバグがあると思います（つまり、バブリングフェーズの合成フォーカスイベントでstopPropagationを呼び出すときに、キャプチャフェーズでネイティブフォーカスイベントの伝播をキャンセルしないでください）。

問題のコードは、ネイティブのキャプチャイベントリスナー、つまりdocument.body.addEventListener('focus', handler, true)

キャプチャされたハンドラーを使用したという事実を考えると、

つまり、ポータルレンダリングを使用するための2つの異なるシナリオがあります。

1. ドロップダウンボタンや1レベルメニューなどの単純なウィジェットでのoverflow：hiddenなどのCSSの問題を防ぐため
2. 次のようなより強力なケースのために新しいUXレイヤーを作成するには：
3. モーダル
4. ネストされたメニュー
5. popovers-with-forms-with-dropdowns -... –すべての場合、レイヤーが結合されている場合

現在のcreatePortal APIは、最初のシナリオのみを満たしていると思います。 新しいReact.renderを2番目に使用するという提案は使用できません。すべてのレイヤーに対して、すべてのプロバイダーを使用して個別のアプリを作成するのは非常に貧弱です。
この問題を解決するために提供できる追加情報は何ですか？
createPortal APIで提案されたパラメータのどのような欠点がありますか？

@sebmarkbageスロットAPIに関する私の直接の質問は、複数のSlotContentsを1つのSlotに同時に挿入できるかどうかです。 私たちのインターフェースでは、複数の「ポップアップ」または「モーダル」を同時に開くことは珍しくありません。 私の完璧な世界では、 Popup APIは次のようになります。

import { App } from './app'
import { PopupSlot } from './popups'

let root = (
  <div>
    <App />
    <PopupSlot />
  </div>
)

ReactDOM.render(root, document.querySelector('#root'))

// some dark corner of our app

import { Popup } from './popups'

export function SoManyPopups () {
  return <>
    <Popup>My Entire</Popup>
    <Popup>Interface</Popup>
    <Popup>Is Popups</Popup>
  </>
}

これには、回避策を完全に見つけることができなかった新しい問題があります。 上記で提案した「イベントトラップ」アプローチを使用すると、ReactSyntheticイベントのみがポータルからのバブリングをブロックされます。 ネイティブイベントは依然としてバブルであり、ReactコードはほとんどjQueryアプリケーション内でホストされているため、 <body>のグローバルjQuerykeyDownハンドラーは引き続きイベントを取得します。

このような参照を介してポータル内のネイティブコンテナ要素にevent.stopPropagationリスナーを追加しようとしましたが、これはポータル内のすべての合成イベントを完全に無効にします-Reactのトップレベルリスナーがキャプチャフェーズを監視していると誤って想定しました。

Reactへの変更以外に、ここで何ができるかわからない。

const allTheEvents: string[] = 'click contextmenu doubleclick drag dragend dragenter dragexit dragleave dragover dragstart drop mousedown mouseenter mouseleave mousemove mouseover mouseout mouseup keydown keypress keyup focus blur change input invalid submit'.split(' ');
const stop = (e: React.SyntheticEvent<HTMLElement>): void => { e.stopPropagation(); };
const nativeStop = (e: Event): void => e.stopPropagation();
const handleRef = (ref: HTMLDivElement | null): void => {
  if (!ref) { return; }
  allTheEvents.forEach(eventName => ref.addEventListener(eventName, nativeStop));
};


/** Prevents https://reactjs.org/docs/portals.html#event-bubbling-through-portals */
export function PortalEventTrap(children: React.ReactNode): JSX.Element {
  return <div
      onClick={stop}
      ...

      ref={handleRef}
    >
      {children}
    </div>;
}

これは、ReactDOMとJQueryが初期化される順序によって異なります。 JQueryが最初に初期化される場合、JQueryのトップレベルのイベントハンドラーが最初にインストールされるため、ReactDOMの合成ハンドラーが実行される前に実行されます。

ReactDOMとJQueryはどちらも、ブラウザがバブリングしないイベント（ scrollなど）がない限り、内部でバブリングをシミュレートするトップレベルリスナーを1つだけ持つことを好みます。

@Kovensky私の理解では、jQueryはReactのように「合成バブリング」を行わなかったため、トップレベルのリスナーは1つもありませんでした。 私のDOMインスペクターも1つを明らかにしません。 私が間違っている場合は、あなたが参照しているものを見てみたいです。

これは、委任されたイベントの場合に当てはまります。 たとえば、 $(document.body).on('click', '.my-selector', e => e.stopPropagation())です。

ほら、これはReactで解決できます。誰かが、コードの再構築が必要な上記の提案された設計では解決できないと私に納得させた場合です。 しかし、私は、迅速な修正の回避策を見つけようとする以外に実行できない理由を見たことがありません。

@sebmarkbageの提案は、直接の所有者に伝播するイベントのケースのみを解決します。 ツリーの残りの部分はどうですか？

これは、SlotsやcreatePortalではうまく解決できないと思うユースケースです。

<Form defaultValue={fromValue}>
   <more-fancy-markup />
   <div>
     <Field name="faz"/>
     <ComplexFieldModal>
       <Field name="foo.bar"/>
       <Field name="foo.baz"/>
     </ComplexFieldModal>
  </div>
</Form>

これは、類似しているがわずかに異なる設定のgifです。ここでは、レスポンシブサイトにcreatePortalを使用して、フォームフィールドをアプリツールバー（ツリーのはるか上）に移動しています。 この場合も、イベントがページのコンテンツに戻ってバブリングすることは本当に望ましくありませんが、フォームコンテキストをそれに合わせて使用​​することは間違いありません。 私の実装は、コンテキストを使用したスロット風のものです...

@sebmarkbage unstable_renderSubtreeIntoContainerは、階層内または別のパッケージ化されたフレームワークの一部として、コンポーネントの位置に関係なく、階層の最上位に直接アクセスできるようにしました。

比較すると、スロットソリューションにはいくつかの問題があります。

• このソリューションは、バブルイベントに「問題がない」階層の位置にアクセスできることを前提としています。 これは、コンポーネントやコンポーネントフレームワークには当てはまりません。
• 階層の他のレベルでイベントをバブルすることは「OK」であると想定します。
• イベントは、スロットの位置から引き続きバブルします。 （ @craigkovatchが述べたように）

ユースケースもあります（おそらくすでに述べたものと似ています）。

ユーザーが「なげなわ」を使ってマウスで物事を選択できる表面があります。 これは基本的に100％の幅/高さであり、私のアプリのルートにあり、 onMouseDownイベントを使用します。 このサーフェスには、モーダルやドロップダウンなどのポータルを開くボタンもあります。 ポータル内のmouseDownイベントは、実際にはアプリのルートにあるなげなわ選択コンポーネントによってインターセプトされます。

私は問題を解決するために多くを見ます：

• ポータルをルート投げ縄コンポーネントの1ステップ上にレンダリングしますが、これはあまり便利ではなく、おそらく、react-gatewayのようなコンテキストベースのライブラリに頼る必要がありますか？ （または、言及されているスロットシステム）。
• ポータルルート内で手動で伝播を停止しますが、上記の望ましくない副作用を引き起こす可能性があります
• Reactポータルでの伝播を停止する機能（+1 btw）
• ポータルからのイベントを除外する

今のところ、私の解決策はイベントを除外することです。

const appRootNode = document.getElementById('root');

const isInPortal = element => isNodeInParent(element, appRootNode);


    handleMouseDown = e => {
      if (!isInPortal(e.target)) {
        return;
      }
      ...
    };

これは明らかに私たち全員にとって最善の解決策ではなく、ネストされたポータルがある場合はあまり良くありませんが、私の現在のユースケース（現在唯一のもの）では機能します。 新しいコンテキストライブラリを追加したり、これを解決するために複雑なリファクタリングを実行したりしたくありません。 私のソリューションを共有したかっただけです。

このスレッドの他の場所で説明されているように、ブロッキングイベントのバブリングを実行することができました。

しかし、私が遭遇しているもう1つの一見厄介な問題は、 onMouseEnter SyntheticEventです。これはバブルしません。 むしろ、ここで説明するように、 fromコンポーネントの共通の親からtoコンポーネントにトラバースします。 つまり、マウスポインターがブラウザーウィンドウの外側から入ると、DOMの上部からcreatePortalのコンポーネントに至るまで、すべてのonMouseEnterハンドラーがこの順序でトリガーされ、あらゆる種類のイベントが発生します。 unstable_renderSubtreeIntoContainerやったことはありません。 onMouseEnterはバブルしないため、ポータルレベルでブロックすることはできません。 （ onMouseEnterイベントは仮想階層を尊重せず、本文のコンテンツを順番に並べず、サブツリーに直接降りたため、これはunstable_renderSubtreeIntoContainer問題ではないようです。）

onMouseEnterイベントがDOM階層の最上位から伝播したり、ポータルサブツリーに直接迂回したりするのを防ぐ方法について誰かがアイデアを持っている場合は、私に知らせてください。

@JasonGore私もこの振る舞いに気づきました。

例えば。

divがonMouseOverをトリガーしたときにレンダリングされるコンテキストメニューがあります。次に、メニューの項目の1つをクリックして、createPortalでモーダルを開きます。 マウスをブラウザウィンドウから外すと、onMouseLeaveイベントがコンテキストメニューまで伝播し、コンテキストメニュー（したがってモーダル）が閉じます...

全体を（リンクとして）クリックできるようにしたいリストアイテムがあるのと同じ問題がありましたが、名前の下のラベルに削除ボタンがあり、確認のためにモーダルが開きます。

私の唯一の解決策は、次のようにモーダルdivでのバブリングを防ぐことでした。

// components/Modal.js

onClick(e) {
    e.stopPropagation();
}

return createPortal(
        <div onClick={this.onClick} ...
            ...

はい、すべてのモーダルでバブリングを防ぐことができますが、それを実現したい場合はまだないので、うまくいきます。

このアプローチには潜在的な問題がありますか？

@jnsandrewは、バブルする他のイベントタイプが約50あることを忘れないでください🙃

これを打つだけです。 ReactがDOMイベントのバブリングとは異なる独自の方法で動作するのは私には厄介なようです。

これに+1。 React.createPortalを使用してiframe内でレンダリングし（スタイルとイベントの分離の両方で）、イベントが箱から出して泡立つのを防ぐことができないのは残念です。

これは、Reactのバックログで12番目に問題が多い問題のようです。 少なくともドキュメントはそれについてオープンですhttps://reactjs.org/docs/portals.html#event-bubbling-through-portals-しかし、彼らは欠点や回避策については言及しておらず、代わりに「より柔軟な抽象化を可能にする」と述べています"：

ドキュメントは、少なくともこれが問題を引き起こす可能性があることを説明し、回避策を提案する必要があります。 私の場合、 https ：

バブリングとキャプチャが一般的にどれほど役立つかはわかりません（Reactは内部でバブリングに依存していることも知っています）-確かに歴史はありますが、コールバックを渡すか、より具体的なイベントを伝播したいと思います（たとえば、おそらく不必要な仲介者の束を介してそのようなものがあるので、バブルアップまたはキャプチャダウンよりも）。 https://css-tricks.com/dangers-stopping-event-propagation/のような記事があり、私は体への伝播に依存するアプリに取り組んでいます。主に「外側」をクリックしたときに物を閉じるためですが、私はむしろすべての上に非表示のオーバーレイを置き、それをクリックして閉じます。 もちろん、Reactのポータルを使用してそのような目に見えないオーバーレイを作成することはできませんでした...

ここにはメンテナンスの悪夢もあります。新しいイベントがDOMに追加されると、上記の手法で「封印」されたポータルは、メンテナンス担当者が（広範な）ブラックリストに追加できるようになるまで、それらの新しいイベントを「リーク」します。

ここには、対処する必要のある主要な設計上の問題があります。 クロスポータルバブリングをオプトインまたはオプトアウトする機能は、依然として私にとって最良のAPIオプションのようです。 実装の難しさについてはよくわかりませんが、1年以上経った今でも、Tableauでこれに関する本番環境のバグが発生しています。

モーダルからの私のフォームが別のフォームを送信している理由を見つけるために2時間を費やしてください。
ついにその問題のおかげでそれを理解しました！

onSubmit伝播がいつ必要になるかを確認するのに本当に苦労しています。 ほとんどの場合、機能というよりはバグのようになります。

少なくとも、ドキュメントに
ポータルを介したイベントバブリングは優れた機能ですが、イベントの伝播を防ぎたい場合もあります。 onSubmit={(e) => {e.stopPropagation()}}追加することでそれを達成できます

これにも+1。 私たちは、使用しているdraftjsをクリック可能なテキスト示すモーダルでheavilly。 そして、フォーカス、選択、変更、キー押下などのモーダルのすべてのイベントは、エラーでdraftjsを爆発させます。

IMO、イベントプロキシの動作は根本的に壊れています（そして私にもバグを引き起こしています）が、これは物議を醸していることを認識しています。 このスレッドは、イベントではなくコンテキストをワームホールするポータルが必要であることを強く示唆しています。 コアチームは同意しますか？ いずれにせよ、ここでの次のステップは何ですか？

ポータルからイベントを伝播することが意図された動作である理由を本当に理解できません。 これは、伝播の主な考え方に完全に反しています。 ポータルは、この種のこと（手動のネスト、イベントの伝播など）を回避するために正確に作成されたと思いました。

ポータルを要素ツリーの近くに配置すると、イベントが伝播されることを確認できます。

class SomeComponent extends React.Component<any, any> {
  render() {
    return <>
      <div className="some-tree">
        // Portal here will bubble events
      </div>
      // Portal here will also bubble events, just checked
    </>
  }
}

この機能リクエストの+1

DOMでは、イベントがDOMツリーをバブルアップします。 Reactでは、イベントがコンポーネントツリーをバブルアップします。

私は既存の動作にかなり依存しています。その一例は、ネストされている可能性のあるポップアウトです。 これらはすべてoverflow: hidden問題を回避するためのポータルですが、ポップアウトを正しく動作させるには、ポップアウトコンポーネントへの外部クリックを検出する必要があります（レンダリングされたDOM要素の外側のクリックを検出するのとは異なります）。 。 より良い例があるかもしれません。

ここでの活発な議論は、両方の行動をとる正当な理由があることを明らかにしたと思います。 createPortalは「プレーンDOM」コンテナノード内にReactコンポーネントをレンダリングするため、Reactの合成イベントがポータルからプレーンオールドDOMツリーに伝播することは機能しないと思います。

ポータルは長い間使用されていないため、デフォルトの動作を「ポータルの境界を越えて伝播しない」に変更するには遅すぎる可能性があります。

これまでのすべての議論に基づいて、私の最も簡単な提案は（まだ）その後、次のとおりです。ポータルの境界を超えてすべてのイベントの伝播を防止するcreatePortalにオプションのフラグを追加します。

より堅牢なものは、残りを停止しながら、境界を「突破」できるようにする必要があるイベントのホワイトリストを提供する機能である可能性があります。

@gaearon Reactチームが実際にこれを引き受けることができる時点にいますか？ これはトップ10の問題ですが、これについてはしばらくの間、あなたから何も聞いていません。

私はこれに私のサポートを追加したいと思います。そして、ReactコンテキストとDOMイベントバブリングの両方をポータル化する方がコンテキストだけをポータル化するよりも概念的に意味があると主張する昨年の@sebmarkbageのコメントに同意し

DOM内のある場所から別の場所にコンテキストをポータル化する機能は、ツールチップ、ドロップダウン、ホバーカード、ダイアログなど、オーバーレイのコンテンツがによって記述され、そのコンテキストでレンダリングされる、あらゆる種類のオーバーレイを実装するのに役立ちます。引き金。 コンテキストはReactの概念であるため、このメカニズムはReactの問題を解決します。 一方、DOMイベントのバブリングをDOM内のある場所から別の場所にポータル化する機能は、DOM構造が明示的に設定したものとは別のものであるかのように見せかける、凝ったトリックです。 これにより、DOMの別の部分に委任する場合に、委任にDOMイベントバブリングを使用する際の問題が解決されます。 Reactを使用している場合は、オーバーレイの内側から外側にバブリングするDOMイベントに依存するのではなく、とにかくコールバック（またはコンテキスト）を使用する必要があります。 他の人が指摘しているように、意図的または意図せずに、オーバーレイ内で発生するイベントに「到達」して処理することはめったにありません。

DOMイベントのバブリングは、主にDOMイベントをDOMターゲットに一致させる問題を解決します。 すべてのクリックは、実際にはネストされた要素のセット全体のクリックです。 高レベルの委任メカニズムであるIMOとして考えるのは最善ではなく、DOMイベントを使用してReactコンポーネントの境界を越えて委任することは、コンポーネントがDOMの予測可能なビットをレンダリングするために使用される小さなプライベートヘルパーコンポーネントでない限り、優れたカプセル化ではありません。

event.target === event.currentTargetは、この問題の解決に役立ちます。 しかし、これは本当に頭痛の種です。

unstable_renderSubtreeIntoContainerを使用してcreatePortalを使用するためにポップオーバーコンポーネントを移行しようとしているときに、これは今日私を苦しめました。 問題のコンポーネントにはドラッグ可能な要素が含まれており、別のドラッグ可能な要素の子孫としてレンダリングされます。 これは、親要素とポップオーバー要素の両方にマウスとタッチのイベントハンドラーが含まれていることを意味します。これらのハンドラーは、ポータルのポップオーバーと対話するときに両方とも起動を開始しました。

unstable_renderSubtreeIntoContainerは廃止されているため（？）、代替ソリューションが必要です。上記の回避策はいずれも、実行可能な長期的なソリューションではないようです。

おい！ このすべての提案をありがとう！
それは私の問題の1つを修正するのに役立ちました。
Reactチームの重要性と能力についての素晴らしい有益な記事を読みたいですか？ 開発に興味のある方ならどなたでもお役に立てればと思います。 幸運を！

IMOは、多くの場合、ポータルでコンテキストへのアクセスを提供しますが、イベントをバブルアップさせたくない場合があります。 Angular 1.xを使用していたとき、 $scopeとテンプレート文字列を受け取り、そのテンプレートをコンパイル/レンダリングして本文に追加する独自のポップアップサービスを作成しました。 そのサービスを使用して、アプリケーションのすべてのポップアップ/モーダル/ドロップダウンを実装しましたが、イベントバブリングの欠如を見逃したことは一度もありませんでした。

stopPropagation()回避策は、 windowネイティブイベントリスナーがトリガーされないように見えます（この場合、 react-dnd-html5-backendによって追加されます）。

この問題の最小限の再現は次のとおりです： https ：

ポータル間での合成バブリングを回避する方法を提供する計画がない場合、おそらく誰かがネイティブイベントバブリングを壊さない回避策を持っていますか？

stopPropagation（）の回避策は、ウィンドウ上のネイティブイベントリスナーがトリガーするのを防ぐように見えます

正しい。 :(

ポータル間での合成バブリングを回避する方法を提供する計画がない場合

コアチームの沈黙にもかかわらず、私とこのスレッドの他の多くの人々は、そのような計画があることを_本当に望んでいます_。

おそらく誰かがネイティブイベントのバブリングを壊さない回避策を持っていますか？

私のチームの回避策は、この明白な問題のためにポータルを完全に禁止することでした。 アプリの他のコンテキスト内に存在するコンテナーへのフックを備えたペインを提示するため、ルートレベルのコンテキストを無料で取得できます。 手動で渡す他のすべて。 素晴らしいとは言えませんが、無意味なモグラたたきイベントハンドラーよりも優れています。

コアチームの誰かによる最後の応答から17か月が経ちまし@ sebmarkbageまたは@gaearon

私のチームの回避策は、この明白な問題のためにポータルを完全に禁止することでした。 アプリの他のコンテキスト内に存在するコンテナーへのフックを備えたペインを提示するため、ルートレベルのコンテキストを無料で取得できます。 手動で渡す他のすべて。 素晴らしいとは言えませんが、無意味なモグラたたきイベントハンドラーよりも優れています。

カスケード小道具に頼ることなく、小道具を介してコンテキストを「偽のポータル」に渡すための一般的なアプローチは考えられません:(

この問題に関連してhttps://github.com/reakit/reakitで見つけたバグは無数にありました。 私はReactPortalをよく使用していますが、ポータルからその親コン​​ポーネントへのイベントバブリングが必要なケースは1つも考えられません。

私の回避策は、親イベントハンドラー内でチェックすることです。

event.currentTarget.contains(event.target);

または、代わりにネイティブイベントを使用します。

const onClick = () => {};
React.useEffect(() => {
  ref.current.addEventListener("click", onClick);
  return () => ref.current.removeEventListener("click", onClick);
});

私はこれらのアプローチをライブラリの内部で使用しています。 しかし、どれも理想的ではありません。 また、これはオープンソースのコンポーネントライブラリであるため、イベントハンドラーをコンポーネントに渡す方法を制御することはできません。

イベントバブリングを無効にするオプションは、これらすべての問題を解決します。

windowイベントのクローンを再トリガーしながら、Reactのバブリングをブロックする半回避策を一緒にハッキングしました。 OSX上のChrome、Firefox、Safariで動作するように見えますが、 event.targetを手動で設定できないため、IE11は省略されています。 これまでのところ、マウス、ポインター、キーボード、ホイールのイベントのみを考慮しています。 ドラッグイベントを複製できるかどうかわからない。

残念ながら、IE11のサポートが必要なため、コードベースでは使用できませんが、他の誰かが自分の用途に合わせて調整できる可能性があります。

これを特に気が遠くなるようなものにしているのは、「デフォルト」の動作がコンポーネントツリーを再びバブルダウンすることです。 次の木を取ります：

<Link>
   <Menu (portal)>
      <form onSubmit={...}>
         <button type="submit">

送信ボタンをクリックするか、フォーム内の入力フィールドでEnterキーを押すかに関係なく、このコンポーネントの正確な組み合わせでフォームのonSubmitが呼び出されない理由について、私は何時間も髪を引っ張っています。

最後に、React Router LinkコンポーネントにonClick実装があり、ブラウザーのリロードを防ぐためにe.preventDefault()を実行していることが原因であることがわかりました。 ただし、これには、フォームの送信である送信ボタンのクリックのデフォルトの動作もブロックするという不幸な副作用があります。 したがって、今日私が学んだのは、送信ボタンを押すためのデフォルトのアクションとして、onSubmitが実際にブラウザーによって呼び出されるということです。 Enterキーを押しても、送信ボタンのクリックがトリガーされ、フォームの送信がトリガーされます。

しかし、イベントのバブリングの順序がこれを本当に奇妙なものにしていることがわかります。

1. <input> [キーを押して入力]
2. <button type="submit"> [シミュレートされたクリック]
3. <Menu> [イベントはポータルの外部に伝播します]
4. <Link> [伝播は親に到達しますLink ]
5. <Link> [ e.preventDefault()呼び出す]
6. =>送信ボタンのクリックに対するデフォルトのブラウザ応答はキャンセルされます
7. =>フォームは送信されません

これは、すでにDOMにボタンとフォームを渡したにもかかわらず発生し、 Linkはそれとは何の関係もなく、この動作をまったくブロックするつもりもありませんでした。

私にとっての解決策（誰かが同じ問題に遭遇した場合）は、 <Menu>コンテンツをonClick={e => e.stopPropagation()} divにラップする一般的に使用される解決策

私にとっての解決策（誰かが同じ問題に遭遇した場合）は、 <Menu>コンテンツをonClick={e => e.stopPropagation()} divにラップする一般的に使用される解決策

うん— _問題の個々のインスタンス_には同じ簡単な解決策があります。_バグを経験し、正しく識別したら_。 Reactチームがここで切り開いたのは、非常に急な壁の失敗の落とし穴であり、彼らからそれについての承認が聞こえないのはイライラします。

mouseenter予期せずポータルからバブリングするという別の問題をデバッグしようとして、数日を費やしました。 ポータルのdivにonMouseEnter={e => e.stopPropagation()}がある場合でも、 https： //github.com/facebook/react/issues/11387#issuecomment -340009465（最初のこの問題についてコメントしてください）。 mouseenter / mouseleaveは、そもそもバブルすることは想定されていません...

おそらくもっと奇妙なことに、ポータルからボタンへのmouseenter合成イベントのバブルを見ると、 e.nativeEvent.typeはmouseoutです。 Reactは、バブリングネイティブイベントに基づいて非バブリング合成イベントをトリガーしています-合成イベントでstopPropagationが呼び出されているにもかかわらず。

@gaearon @trueadmこの問題は、2年以上にわたって一貫した大きなフラストレーションを引き起こしてきました。 このスレッドは、Reactで最も活発な問題の1つです。 お願いします、チームの誰かがここで貢献できますか？

私の場合、ボタンをクリックしてウィンドウコンポーネントを開くと、ウィンドウをクリックするとボタンがクリックされて状態が変化するため、ウィンドウが消えました。

私はReactを初めて使用します。主に、jQueryとvanillia JSを使用しますが、これは驚くべきバグです。 この動作が予想される場合は、1％程度になる可能性があります...

@diegohazの2つのソリューションが好きですが、それでもcreatePortalはイベントのバブリングを停止するオプションがあるはずだと思います。

私の特定のユースケースは、ツールチップのonMouseLeaveおよびonMouseEnterハンドラーが、その子のポータルの子孫によってトリガーされる場合でした。これは望ましくありませんでした。 ネイティブイベントは、ポータルの子孫がdomの子孫ではないため、ポータルの子孫を無視することでこれを修正しました。

ポータルでのバブリングを停止するオプションの+1。 ポータルを（子ではなく）兄弟として、イベントリスナーが発生しているコンポーネントに配置することが提案されましたが、多くのユースケース（私のものを含む）では機能しないと思います。

最終的にReactDOM.unstable_renderSubtreeIntoContainerが削除されるようです。つまり、この問題に対する合理的な回避策はすぐに残っていないことを意味します...

^私たちを助けてください@ trueadm

GitHubでpingを実行できないようです😞
おそらく、アクティブなTwitterアカウントを持っている人が、投稿者の1人にタグを付けて、これについてツイートする可能性がありますか？

この問題に+1を追加します。 Notionでは、現在、 React.createPortalより前のカスタムポータル実装を使用しており、コンテキストプロバイダーを新しいツリーに手動で転送しています。 React.createPortalを採用しようとしましたが、予期しないバブリング動作によってブロックされました。

<Portal> <MenuItem>コンポーネントの外に移動して兄弟になるという@sebmarkbageの提案は、単一のネストレベルの問題を解決するだけです。 サブメニューをポータル化する複数のネストされた（たとえば）メニュー項目がある場合、問題は残ります。

この問題は自動的に古くなったものとしてマークされています。 この問題が引き続き影響する場合は、コメント（「バンプ」など）

バンプ。

ダンは関連する問題についてコメントを残しまし

@mogelbrod現在、これに追加するものはありませんが、既存のコンポーネントを移行する場合は、このようなもの（ ＃11387（コメント） ）が妥当と思われます。

同じ問題でのダンによるフォローアップ：

回避策についてのコンテキストをありがとう。 あなたはすでにそのドメイン知識を持っているので、次の最良のステップはおそらくあなたが望む振る舞いとあなたが考えた代替案のためのRFCを書くことです： https ：

それにもかかわらず、 unstable_renderSubtreeIntoContainerはサポートされていないので、これら2つの議論を解き明かしましょう。 API全体が凍結されて更新されないため、コンテキストの伝播を追加しません。

議論されたフラグの追加、またはおそらく別の解決策を提案するために、ReactRFCを確実に公開する必要があります。 ドラフトに特に興味を持っている人はいますか（おそらく@ justjake 、 @ craigkovatch 、または@jquense）？ そうでなければ、私は私が思いつくことができるものを見るでしょう！

このAPIを進化させることに興味はありますが、RFCのドラフトには興味がありません。 ほとんどの場合、これは大量の作業であり、受け入れられる可能性はほとんどありません。コアチームが実際にロードマップにないRFCを検討しているとは思いません。

@jquenseこれは正確ではないと思います。 はい。新しいAPIの追加は常に分野横断的であり、他のすべての計画された機能に影響を与えるため、ビジョンに沿っていないRFCをマージすることはほとんどありません。 そして、うまくいかないものについてはあまりコメントしないのは公平です。 ただし、特にエコシステムがより専門知識を持っているトピックにアプローチする場合は、それらを読み通します。例として、 ：//github.com/reactjs/rfcs/pull/38、https：//github.com/ reactjs / rfcs / pull / 150 、 https ： //github.com/reactjs/rfcs/pull/118、https：//github.com/reactjs/rfcs/pull/109、https：//github.com/reactjs/ rfcs / pull / 32は、明示的にコメントしていなくても、すべて私たちの思考に影響を与えてきました。

言い換えれば、私たちはコミュニティ研究メカニズムとして部分的にRFCにアプローチします。 @mogelbrod （https://github.com/facebook/react/issues/16721#issuecomment-674748100）からのこの回避策が煩わしい理由についてのコメントは、まさにRFCで見たいものです。 既存のソリューションとその欠点を検討することは、具体的なAPI提案の提案よりも価値があります。

@gaearon私のコメントは、チームが外部のフィードバックに耳を傾けないことを示唆するものではありません。 Yaはそれをうまくやるでしょう。 私のコメントは正確だと思います。 RFCリポジトリで実行される_process_は、他の人々から受け入れられたRFCにはなりません。 どのRFCがマージされるかを見ると、それは完全にコアチームメンバーまたはfb従業員であり、他には誰もいません。 それを実現する機能は、通常は少し異なり、RFCプロセスにはまったく参加しません（同形IDなど）。

他のRFCを見て、それらが機能の設計に貢献していると聞いてとてもうれしく思いますが、「コメントしたことはありませんが、これらの外部RFCの影響を受けました」と私は考えています。それに挑戦します。

言い換えれば、私たちはコミュニティ研究メカニズムとして部分的にRFCにアプローチします。

これは非常に合理的ですが、RFCリポジトリが_its_アプローチと言っていることではなく、他の人々がRFCを一般的にどのように考えているかでもありません。 RFCプロセスは通常、チームとコミュニティの間のリンクとコミュニケーションのポイントであり、機能の検討とプロセスの観点からも、ある程度の競争の場です。

コミュニティガバナンスについてのより大きなポイントはさておき。 人々に、詳細な提案を書くのに時間を費やし、反応チームからの沈黙に会いながら他の外部の参加者にそれらを守るように頼むことは失望し、FBがOSSに対する自身のニーズだけを気にしているという印象を積極的に強めます。 私はあなたがそのように感じたりデザインしたりしないことを知っているので、これは悪臭を放ちます。

RFCプロセスが次のようになっている場合：「ここで、懸念事項とユースケースの概要を説明し、この機能を実装できるようになったときに、それらを読みます」。 正直なところ、それは素晴らしいアプローチです。 コミュニティは、明示的に説明されていることから恩恵を受けると思います。そうでない場合、pplは、他のRFCプロセスが頻繁に行うのと同じレベルの関与と参加を想定し、それが実行されない場合は積極的に落胆します。 他の寄稿者よりも少し洞察力があったとしても、確かにその印象を持っています。

確かに、私はそのすべてに同意すると思います。 これをメタスレッドに変えたくはありませんが、人々はこのスレッドについてpingを繰り返しているので、これを前進させるために最も実用的なことは、両方に懸念を抱く、どのように機能するかについての提案を書くことです。

十分に公平ですが、これはRFCでメタを取得するのに適切な場所ではありません:)

@gaearonこれは、現在Reactで開かれている6番目に賛成の問題であり、4番目にコメントされています。 React 16がリリースされてからオープンしており、3歳からわずか2か月です。 それでも、Reactコアチームからの関与はほとんどありません。 それだけの時間と苦痛が過ぎて起こった後、「解決策を提案するのはコミュニティ次第だ」と言うのは非常に否定的です。 いくつかの非常に便利なアプリケーションがありますが、デフォルトであるこの動作は設計上の誤りであったことを認識してください。 それを修正するのはRFCのコミュニティ次第ではありません。

この問題についてコメントしたことを後悔し、コミュニティRFCに関する提案を撤回します。 そうです、それはおそらく悪い考えです。 この問題は非常に感情的になっていることを付け加えなければなりません。人間として、私はこの問題に取り組むのが難しいと感じています。それは重要であり、多くの人々が強く感じていることを理解していますが。

このスレッドの状態について簡単に返信します。

まず、このスレッドでフォローアップを継続しなかったことにコメントし、不満を感じている人々に謝罪したいと思います。 この問題を外部から読んでいたとしたら、Reactチームが間違いを犯し、それを認めたくなく、簡単な解決策に進んでいるという印象だったでしょう（「ブール値を1つ追加するだけで、どれだけ難しいか彼らはコミュニティを気にしないので、2年以上の間です。 私はあなたがこの結論に達するかもしれない方法を完全に理解することができます。

私はこの問題が非常に賛成されていることを知っています。 これは、このスレッドで何度も取り上げられています。おそらく、Reactチームがこれが大きな問題点であることを知っていれば、もっと早く対処できただろうという観点からです。 これが問題点であることはわかっています。人々は定期的に私たちにそれについて個人的にメッセージを送ったり、Reactチームがコミュニティを気にしない方法の例としてそれを保持したりします。 沈黙が苛立たしいことを私は完全に認めますが、「何かをするだけ」という高まる圧力により、この問題に生産的に取り組むことがより困難になっています。

この問題には回避策があります。これにより、緊急に対処する必要のあるセキュリティの脆弱性やクラッシュとは異なります。 wokaroundsは、特にReact 16より前に作成されたコードの周りで使用しているため、機能することはわかっています（ただし、理想的ではなく、煩わしい場合もあります）。多くの人が、具体的な時間枠内で対応しなければならないクラッシュやセキュリティの問題とはまだ異なるクラスの問題にあります。

さらに、明日実装できる簡単なソリューションがあるというフレーミングにも同意しません。 最初の動作を間違いだと考えても（同意するかどうかはわかりませんが）、次の動作でさまざまなユースケースを処理するための基準はさらに高くなります。 いくつかのケースを修正し、他のケースを壊した場合、私たちは何の進展も見られず、大量の解約を生み出しました。 この問題では、現在の動作がうまく機能するケースについては耳にしないことに注意してください。 私たちはそれを壊した後にのみそれについて聞くでしょう。

例を挙げると、現在の動作は、私たちがかなり長い間調査してきた宣言型フォーカス管理のユースケースに実際に役立ちます。 ポータルであるにもかかわらず、フォーカス/ブラーをパーツツリーに関してモーダルの「内部」で発生するものとして扱うと便利です。 このスレッドで提案されている「単純な」 createPortal(tree, boolean)提案を出荷する場合、ポータル自体が必要な動作を「知る」ことができないため、このユースケースは機能しません。 考えられる解決策を探るには、数十のユースケースを検討する必要があり、そのうちのいくつかはまだ完全には理解されていません。 これは確かにある時点で行う必要がありますが、それを正しく行うための多大な時間のコミットメントでもあり、これまでのところ私たちはそれに集中することができませんでした。

特にイベントは厄介な領域です。たとえば、何年にもわたる問題に対処するために多くの変更を加えたばかりであり、これは今年大きな焦点となっています。 しかし、一度にできることはたくさんあります。

一般的に、私たちはチームとして、多くの問題を浅くするのではなく、いくつかの問題に深く焦点を合わせようとします。 残念ながら、これは、他の重要なギャップを修正している最中であるか、問題を完全に解決する代替設計がないために、いくつかの概念上の欠陥やギャップが何年も埋められない可能性があることを意味します。 私はこれを聞くのがイライラすることを知っています、そしてそれは私がこのスレッドから離れた理由の一部です。 他のいくつかの同様のスレッドは、問題と考えられる解決策のより深い説明になりました。これは役に立ちますが、これは主に「+1」の洪水と「単純な」修正の提案になりました。そのため、それは困難でした。有意義にそれに従事する。

これが人々が聞きたかった答えではないことは知っていますが、まったく答えがないよりはましだと思います。

指摘する価値のあるもう1つの点は、このスレッドで説明されている問題点のいくつかは、他の方法で解決された可能性があるということです。 例えば：

具体的には、合成フォーカスイベントでstopPropagationを呼び出して、ポータルからのバブリングを防止すると、＃document上のReactのキャプチャされたハンドラーのネイティブフォーカスイベントでもstopPropagationが呼び出されます。つまり、上の別のキャプチャされたハンドラーには到達しませんでした。

Reactは、バブリングをエミュレートするためにキャプチャフェーズを使用しなくなり、ドキュメントのイベントをリッスンしなくなりました。 したがって、フラストレーションを解消することなく、他の変更を考慮して、これまでに投稿されたすべてのものを再評価する必要があります。

ネイティブイベントはまだバブルであり、Reactコードは主にjQueryアプリケーション内でホストされているため、グローバルjQuerykeyDownハンドラーは

まだイベントを取得します。

同様に、React 17はイベントをルートとポータルコンテナにアタッチします（そして実際にはその時点でネイティブの伝播を停止します）ので、私も解決されることを期待しています。

renderSubtreeIntoContainer削除に関するポイントについて。 文字通り、 ReactDOM.renderとの唯一の違いは、レガシーコンテキストを伝播することです。 renderSubtreeIntoContainerを含まないリリースには、レガシーコンテキストも含まれないため、 ReactDOM.renderは100％同一の代替手段のままになります。 もちろん、これはより広い問題を解決するものではありませんが、 renderSubtreeに関する懸念は特に見当違いだと思います。

@gaearon

renderSubtreeIntoContainer削除に関するポイントについて。 文字通り、 ReactDOM.renderとの唯一の違いは、レガシーコンテキストを伝播することです。 renderSubtreeIntoContainerを含まないリリースには、レガシーコンテキストも含まれないため、 ReactDOM.renderは100％同一の代替手段のままになります。 もちろん、これはより広い問題を解決するものではありませんが、 renderSubtreeに関する懸念は特に見当違いだと思います。

あなたがそれについて言及したので、以下のコードはイベントバブリングなしでReactポータルの有効で安全な実装になるのだろうかと思います：

function Portal({ children }) {
  const containerRef = React.useRef();

  React.useEffect(() => {
    const container = document.createElement("div");
    containerRef.current = container;
    document.body.appendChild(container);
    return () => {
      ReactDOM.unmountComponentAtNode(container);
      document.body.removeChild(container);
    };
  }, []);

  React.useEffect(() => {
    ReactDOM.render(children, containerRef.current);
  }, [children]);

  return null;
}

いくつかのテストを含むCodeSandbox： https ：//codesandbox.io/s/react-portal-with-reactdom-render-m22dj？file = / src / App.js

モダンコンテキストを通過させないという問題はまだありますが、これは新しい問題ではありません（ renderSubtreeも影響を受けます）。 回避策は、ツリーを多数のコンテキストプロバイダーで囲むことです。 全体として、ツリーをネストすることは理想的ではないため、レガシーの既存のコードシナリオ以外では、このパターンに移行することはお勧めしません。

繰り返しになりますが、@ gaearonの記事をありがとうございました！

壊れたケースのリストと回避策（React v17用に更新）を集約することが、コアチーム外の誰かにとって最も生産的なものになるようです（間違っている場合は訂正してください！）。

私は今後数週間で圧倒されますが、できるだけ早くすることを目指しています。 他の誰かが以前にこれを行うことができた場合、またはスニペットでチャイムを鳴らした場合（ @diegohazが行ったように）、それは素晴らしいことです！

ケースのリストを集約することは間違いなく役に立ちますが、壊れたケースだけでなく、現在の動作が理にかなっているケースも含める必要があると思います。

追加するパブリックスペースがある場合は、アプリとUIライブラリの作成者の両方からユースケースを追加できれば幸いです。 一般的に、私はダンに同意します。それは時々煩わしいものですが、回避するのは簡単です。 Reactのバブリングが必要な場合は、Reactの助けがなければケースをカバーするのは非常に困難です。

ケースのリストを集約することは間違いなく役に立ちますが、壊れたケースだけでなく、現在の動作が理にかなっているケースも含める必要があると思います。

誰かがそれに依存するオープンソースコード/抽出コードを私に指摘できれば、これらを含めて喜んでいます！ 前に述べたように、現在の動作に問題がある人だけがこの問題に関与しているので、見つけるのは少し難しいです😅

追加するパブリックスペースがある場合は、アプリとUIライブラリの作成者の両方からユースケースを追加できれば幸いです。 一般的に、私はダンに同意します。それは時々煩わしいものですが、回避するのは簡単です。 Reactのバブリングが必要な場合は、Reactの助けがなければケースをカバーするのは非常に困難です。

念頭に置いている特定のスペース、またはケースごとに1つのコードサンドボックス（またはjsfiddleなど）を共有することは、スターターとして機能しますか？ いくつかのケースを集めたら、それらすべてをコンパイルしてみることができます。

ここでスレッドを開始しました： https ：