React: createPortal: रिएक्ट ट्री में घटनाओं के प्रसार को रोकने के लिए समर्थन विकल्प

साथ ही, माउसओवर/छुट्टी का प्रचार पूरी तरह से अप्रत्याशित दिखता है।

क्या आप पोर्टल को बटन के बाहर ले जा सकते हैं?

जैसे

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

तब यह बटन के माध्यम से बुलबुला नहीं होगा।

यह मेरा पहला विचार था, लेकिन!) कल्पना कीजिए कि हमारे पास ऐसे घटक कंटेनर में माउस एंटर हैंडलर है:

unstable_rendersubtreeintocontainer मुझे ButtonWithPopover घटक में घटनाओं से कोई लेना-देना नहीं है - mouseEnter बस तब काम करता है जब माउस वास्तव में div और बटन DOM तत्व में प्रवेश करता है, और जब माउस पॉपओवर पर होता है तो निकाल दिया नहीं जाता है। पोर्टल के साथ, जब माउस पॉपओवर पर होता है तो ईवेंट सक्रिय हो जाता है - और वास्तव में इस समय div से अधिक नहीं होता है। इसलिए, मुझे प्रचार को रोकने की जरूरत है। अगर मैं इसे ButtonWithPopover घटक में करता हूं, तो माउस खत्म होने पर मैं ईवेंट फायरिंग तोड़ दूंगा। अगर मैं इसे पॉपओवर में करता हूं और मैं इस एप्लिकेशन के लिए कुछ सामान्य पॉपओवर घटक का उपयोग कर रहा हूं, तो मैं अन्य ऐप भागों में तर्क भी तोड़ सकता हूं।

मैं वास्तव में रिएक्ट ट्री के माध्यम से बुदबुदाहट के उद्देश्य को नहीं समझता। अगर मुझे पोर्टल घटक से घटनाओं की आवश्यकता है - मैं बस प्रोप के माध्यम से हैंडलर पास कर सकता हूं। हम इसे unstable_rendersubtreeintocontainer साथ कर रहे थे और इसने सही काम किया।

अगर मैं प्रतिक्रिया पेड़ में गहरे कुछ बटन से एक मोडल विंडो खोलूंगा, तो मुझे मोडल के तहत घटनाओं की अप्रत्याशित फायरिंग प्राप्त होगी। stopPropagation भी डोम में प्रचार को रोक देगा, और मुझे ऐसी घटनाएं नहीं मिलेंगी जिन्हें मैं वास्तव में निकाल दिया जाना चाहता हूं (

@gaearon मैं सुझाव unstable_rendersubtreeintocontainer का उपयोग कर रहे थे)। इनमें से कुछ को माउस ईवेंट को फ़िल्टर करने के लिए एक अतिरिक्त div परत के साथ भी तय नहीं किया जा सकता है क्योंकि उदाहरण के लिए हम ड्रैग करने योग्य संवादों को लागू करने के लिए दस्तावेज़ तक प्रचारित करने वाले mousemove ईवेंट पर भरोसा करते हैं।

भविष्य में रिलीज में इसे संबोधित करने से पहले इसे हल करने का कोई तरीका है?

मुझे लगता है कि इसे फीचर अनुरोध कहा जा रहा है, क्योंकि पोर्टल्स का वर्तमान बबल व्यवहार अपेक्षित और इरादा दोनों है। लक्ष्य यह है कि सबट्री अपने माता-पिता के असली बच्चे की तरह काम करे।

अतिरिक्त उपयोग के मामलों या स्थितियों (जैसे आप देख रहे हैं) जो आपको नहीं लगता कि वर्तमान कार्यान्वयन द्वारा सेवा की जाती है, या उन्हें हल करना मुश्किल है, क्या मददगार होगा

मैं समझता हूं कि इस व्यवहार का इरादा है, लेकिन मुझे लगता है कि यह एक महत्वपूर्ण बग है कि यह अक्षम-सक्षम नहीं है।

मेरे दिमाग में डीओएम के साथ काम करने वाले पुस्तकालय को डीओएम कार्यान्वयन व्यवहार को संरक्षित करना चाहिए, इसे तोड़ना नहीं चाहिए।

उदाहरण के लिए:

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>
  );
}

जब मैं डोम के साथ काम करता हूं, तो मुझे उम्मीद है कि डीओएम कार्यान्वयन जैसे कार्यक्रम प्राप्त होंगे। मेरे उदाहरण में घटनाओं को पोर्टल के माध्यम से प्रचारित किया जाता है, इसके डीओएम माता-पिता के आसपास काम कर रहे हैं, और इसे एक बग के रूप में माना जा सकता है।

दोस्तों चर्चा के लिए धन्यवाद, हालांकि मुझे नहीं लगता कि यह बहस करने में मददगार है कि कुछ बग है या नहीं। इसके बजाय मैं उन उपयोग मामलों और उदाहरणों पर चर्चा करने के लिए अधिक उत्पादक होगा जो वर्तमान व्यवहार से नहीं मिलते हैं, इसलिए हम बेहतर ढंग से समझ सकते हैं कि वर्तमान तरीका भविष्य के लिए सबसे अच्छा तरीका है या नहीं।

आम तौर पर हम चाहते हैं कि एपीआई उपयोग-मामलों के विविध सेट को संभाले, जबकि उम्मीद है कि दूसरों को अत्यधिक सीमित न करें। मैं कोर टीम के लिए बात नहीं कर सकता, लेकिन मुझे लगता है कि इसे कॉन्फ़िगर करने योग्य बनाना एक संभावित समाधान नहीं है। आम तौर पर रिएक्ट कॉन्फ़िगर करने योग्य पर एक सुसंगत एपीआई के लिए झुक जाता है।

मैं यह भी समझता हूं कि यह व्यवहार यह नहीं है कि डीओएम कैसे काम करता है, लेकिन मुझे नहीं लगता कि यह कहने का एक अच्छा कारण है कि ऐसा नहीं होना चाहिए। बहुत से प्रतिक्रिया-डोम का व्यवहार डीओएम के काम करने के तरीके से अलग है, हो सकता है कि घटनाएं पहले से ही मूल संस्करण से अलग हों। उदाहरण के लिए onChange पूरी तरह से मूल परिवर्तन घटना के विपरीत है, और DOM के विपरीत, सभी प्रतिक्रियाएँ प्रकार की परवाह किए बिना बबल करती हैं।

इसके बजाय मैं उपयोग के मामलों और उदाहरणों पर चर्चा करने के लिए और अधिक उत्पादक होगा जो वर्तमान व्यवहार से नहीं मिलते हैं

यहां दो उदाहरण दिए गए हैं जो हमारे लिए रिएक्ट 16 में प्रवासन में टूट गए हैं।

सबसे पहले, हमारे पास एक ड्रैग करने योग्य संवाद है जो एक बटन द्वारा लॉन्च किया जाता है। मैंने अपने पोर्टल उपयोग पर एक "फ़िल्टरिंग" तत्व जोड़ने का प्रयास किया, जिसे किसी भी माउस* एक कुंजी* ईवेंट पर StopPropagation कहा जाता है। हालांकि, हम ड्रैगिंग कार्यक्षमता को लागू करने के लिए एक मूसमूव घटना को दस्तावेज़ में बाँधने में सक्षम होने पर भरोसा करते हैं - यह सामान्य है क्योंकि यदि उपयोगकर्ता माउस को किसी भी महत्वपूर्ण दर पर ले जाता है, तो कर्सर संवाद की सीमा को छोड़ देता है और आपको आवश्यकता होती है उच्च स्तर पर माउस की गति को पकड़ने में सक्षम होने के लिए। इन घटनाओं को फ़िल्टर करने से यह कार्यक्षमता टूट जाती है। लेकिन पोर्टल्स के साथ, माउस और प्रमुख घटनाएं संवाद के अंदर से उस बटन तक बुदबुदाती हैं जिसने इसे लॉन्च किया है, जिससे यह विभिन्न दृश्य प्रभाव प्रदर्शित करता है और यहां तक ​​​​कि संवाद को खारिज कर देता है। मुझे नहीं लगता कि इस घटना के प्रसार को रोकने के लिए 10-20 ईवेंट हैंडलर को बाध्य करने के लिए पोर्टल के माध्यम से लॉन्च किए जाने वाले प्रत्येक घटक की अपेक्षा करना यथार्थवादी है।

दूसरा, हमारे पास एक पॉपअप संदर्भ मेनू है जिसे प्राथमिक- या द्वितीयक-माउस क्लिक द्वारा लॉन्च किया जा सकता है। हमारे पुस्तकालय के आंतरिक उपभोक्ताओं में से एक के पास इस मेनू को लॉन्च करने वाले तत्व से जुड़े माउस हैंडलर हैं, और निश्चित रूप से मेनू में आइटम चयन को संभालने के लिए क्लिक हैंडलर भी हैं। मेनू अब हर क्लिक पर फिर से दिखाई दे रहा है क्योंकि माउसडाउन/माउसडाउन ईवेंट मेनू को लॉन्च करने वाले बटन पर बैक अप बबल कर रहे हैं।

मैं कोर टीम के लिए बात नहीं कर सकता, लेकिन मुझे लगता है कि इसे कॉन्फ़िगर करने योग्य बनाना एक संभावित समाधान नहीं है। आम तौर पर रिएक्ट कॉन्फ़िगर करने योग्य पर एक सुसंगत एपीआई के लिए झुक जाता है।

मैं आपसे (और टीम से) इस विशेष मामले में इस स्थिति पर पुनर्विचार करने का अनुरोध करता हूं। मुझे लगता है कि कुछ उपयोग के मामलों के लिए घटना बबलिंग दिलचस्प होगी (हालांकि मैं किसी भी ऑफहैंड के बारे में नहीं सोच सकता)। लेकिन मुझे लगता है कि यह दूसरों में अपंग होगा, और यह एपीआई में महत्वपूर्ण असंगति का परिचय देता है। जबकि unstable_rendersubtreeintocontainer कभी भी सुपर-समर्थित नहीं था, यह वही था जो हर कोई तत्काल पेड़ के बाहर प्रस्तुत करता था, और यह इस तरह से काम नहीं करता था। इसे पोर्टल के पक्ष में आधिकारिक रूप से बहिष्कृत कर दिया गया था, लेकिन पोर्टल इस महत्वपूर्ण तरीके से कार्यक्षमता को तोड़ते हैं, और एक आसान समाधान प्रतीत नहीं होता है। मुझे लगता है कि इसे काफी असंगत के रूप में वर्णित किया जा सकता है।

मैं यह भी समझता हूं कि यह व्यवहार यह नहीं है कि डीओएम कैसे काम करता है, लेकिन मुझे नहीं लगता कि यह कहने का एक अच्छा कारण है कि ऐसा नहीं होना चाहिए।

मैं समझता हूं कि आप यहां से कहां आ रहे हैं, लेकिन मुझे लगता है कि इस मामले में (ए) यह एक मौलिक व्यवहार है जिसका (बी) वर्तमान में कोई समाधान नहीं है, इसलिए मुझे लगता है कि "डीओएम इस तरह से काम नहीं करता" एक मजबूत तर्क है, अगर पूरी तरह से आश्वस्त नहीं है।

और स्पष्ट होने के लिए: मेरा अनुरोध है कि इसे एक बग माना जाए, ताकि इसे जल्द से जल्द ठीक करने के लिए प्राथमिकता दी जाए।

पोर्टल का मेरा मानसिक मॉडल यह है कि यह व्यवहार करता है जैसे कि यह पेड़ में एक ही स्थान पर है, लेकिन "ओवरफ्लो: छुपा" जैसी समस्याओं से बचा जाता है और ड्राइंग/लेआउट उद्देश्यों के लिए स्क्रॉलिंग से बचाता है।

पोर्टल के बिना इनलाइन होने वाले कई समान "पॉपअप" समाधान हैं। उदाहरण के लिए, एक बटन जो इसके ठीक बगल में एक बॉक्स का विस्तार करता है।

एक उदाहरण के रूप में यहाँ GitHub पर "अपनी प्रतिक्रिया चुनें" संवाद लें। इसे बटन के ठीक बगल में एक div के रूप में लागू किया गया है। यह अब ठीक काम करता है। हालांकि, अगर यह एक अलग z-index रखना चाहता है, या एक overflow: scroll क्षेत्र से बाहर निकलना चाहता है जिसमें ये टिप्पणियां हैं, तो उसे DOM स्थिति बदलने की आवश्यकता होगी। यह परिवर्तन तब तक सुरक्षित नहीं है जब तक कि ईवेंट बबलिंग जैसी अन्य चीजें भी संरक्षित न हों।

"पॉपअप" या "पॉप आउट" की दोनों शैलियाँ वैध हैं। तो आप उसी समस्या को कैसे हल करेंगे जब घटक लेआउट में इनलाइन हो, इसके बाहर तैरने के विपरीत?

मेरे लिए काम करने वाला वर्कअराउंड सीधे पोर्टल रेंडरिंग के तहत stopPropagation कॉल कर रहा है:

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

यह मेरे लिए बहुत अच्छा काम करता है क्योंकि मेरे पास एकल अमूर्त घटक है जो पोर्टल का उपयोग करता है, अन्यथा आपको अपने सभी createPortal कॉल को ठीक करने की आवश्यकता होगी।

@ मिथाइल यह मानता है कि आप हर उस घटना को जानते हैं जिसे आपको पेड़ को बुदबुदाने से रोकने की जरूरत है। और मामले में मैंने ड्रैग करने योग्य संवादों के साथ उल्लेख किया है, हमें दस्तावेज़ को बबल अप करने के लिए mousemove है, लेकिन रेंडर ट्री को बबल करने के लिए नहीं ।

"पॉपअप" या "पॉप आउट" की दोनों शैलियाँ वैध हैं। तो आप उसी समस्या को कैसे हल करेंगे जब घटक लेआउट में इनलाइन हो, इसके बाहर तैरने के विपरीत?

@sebmarkbage मुझे यकीन नहीं है कि यह सवाल समझ में आता है। अगर मुझे घटक को इनलाइन करने में यह समस्या होती, तो मैं इसे इनलाइन नहीं करता।

मुझे लगता है कि समस्या यहाँ से कुछ से कुछ उपयोग के मामलों है renderSubtreeIntoContainer पर वापस पोर्ट किया जा रहा है createPortal जब दो तरीकों धारणात्मक अलग अलग बातें कर रहे हैं। मुझे लगता है कि पोर्टल की अवधारणा को अतिभारित किया जा रहा था।

मैं मानता हूं कि मोडल संवाद मामले में, आप लगभग कभी नहीं चाहते कि मोडल उस बटन के बच्चे की तरह कार्य करे जिसने इसे खोला था। ट्रिगर घटक इसे केवल इसलिए प्रस्तुत कर रहा है क्योंकि यह open स्थिति को नियंत्रित करता है। मुझे लगता है कि यह कहना एक गलती है कि पोर्टल कार्यान्वयन गलत है, यह कहने के बजाय कि बटन में createPortal लिए सही उपकरण नहीं है। इस मामले में मोडल ट्रिगर का बच्चा नहीं है, और इसे इस तरह प्रस्तुत नहीं किया जाना चाहिए जैसे कि यह था। एक संभावित समाधान renderSubtreeIntoContainer का उपयोग करना जारी रखना है, दूसरा उपयोगकर्ता-भूमि विकल्प ऐप रूट के पास ModalProvider जो रेंडरिंग मोडल्स को संभालता है, और एक रेंडर करने के लिए एक विधि (संदर्भ के माध्यम से) पास करता है मनमाना मोडल तत्व को जड़ की जरूरत है

renderSubtreeIntoContainer को रिएक्ट 16 में render या जीवनचक्र विधियों के अंदर से नहीं बुलाया जा सकता है, जो उन मामलों के लिए इसके उपयोग को रोकता है जिन पर मैं चर्चा कर रहा हूं (वास्तव में, हमारे सभी घटक जो थे ऐसा करने से 16 के प्रवासन में पूरी तरह से टूट गया)। पोर्टल आधिकारिक सिफारिश हैं: https://reactjs.org/blog/2017/09/26/react-v16.0.html#break -changes

मैं मानता हूं कि पोर्टल की अवधारणा शायद अतिभारित हो गई है। मुझे यकीन नहीं है कि मुझे इसके लिए वैश्विक घटक और संदर्भ का समाधान पसंद है, हालांकि। ऐसा लगता है कि इसे आसानी से createPortal पर ध्वज द्वारा हल किया जा सकता है, यह निर्दिष्ट करता है कि घटनाओं को बबल करना चाहिए या नहीं। यह एक ऑप्ट-इन फ़्लैग होगा जो 16+ के साथ API संगतता बनाए रखेगा।

मैं पोर्टलों के हमारे उपयोग-मामले को स्पष्ट करने का प्रयास करूंगा और हम घटनाओं के प्रसार को रोकने के लिए एक विकल्प देखना क्यों पसंद करेंगे। ManyChat ऐप में, हम 'लेयर्स' बनाने के लिए पोर्टल्स का उपयोग कर रहे हैं। हमारे पास पूरे ऐप के लिए लेयर सिस्टम है जो कई प्रकार के घटकों द्वारा उपयोग किया जाता है: पॉपओवर, ड्रॉपडाउन, मेनू, मोडल। प्रत्येक परत एक नई परत को उजागर कर सकती है, उदाहरण के लिए मेनू के दूसरे स्तर पर बटन मोडल विंडो को ट्रिगर कर सकता है जहां दूसरा बटन पॉपओवर खोल सकता है। ज्यादातर मामलों में परत यूएक्स की नई शाखा है जो अपने स्वयं के कार्य को हल करती है। और जब नई परत खुली होती है, तो उपयोगकर्ता को इस नई परत के साथ बातचीत करनी चाहिए, न कि नीचे के अन्य लोगों के साथ। इसलिए, इस प्रणाली के लिए, हमने परत को प्रस्तुत करने के लिए एक सामान्य घटक बनाया है:

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)
  }
  ...
}

यह घटक रिएक्ट डॉक्स से सभी प्रकार के ईवेंट के लिए प्रसार को रोकता है, और इसने हमें रिएक्ट 16 में अपडेट करने की अनुमति दी।

क्या इसे पोर्टलों से जोड़ने की आवश्यकता है? सैंडबॉक्सिंग पोर्टल के बजाय, क्या होगा यदि केवल (उदाहरण के लिए) <React.Sandbox>...</React.Sandbox> ?

यह भी मुझे अनावश्यक रूप से जटिल लगता है। बबलिंग व्यवहार को अवरुद्ध करने की इजाजत देने के लिए पोर्टल बनाने के लिए बस एक वैकल्पिक बूलियन ध्वज क्यों न जोड़ें?

@gaearon यह हम में से एक निश्चित टुकड़े के लिए एक बहुत ही दुर्भाग्यपूर्ण स्थिति है - क्या आप या आपका कोई प्रिय इस पर एक नज़र डाल सकता है? :)

मैं जोड़ूंगा कि मेरी वर्तमान सोच यह है कि दोनों उपयोग मामलों का समर्थन किया जाना चाहिए। वास्तव में ऐसे मामलों का उपयोग होता है जहां आपको वर्तमान माता-पिता से उपट्री में प्रवाह करने के लिए संदर्भ की आवश्यकता होती है, लेकिन उस उपट्री को डीओएम के संदर्भ में तार्किक बच्चे के रूप में कार्य नहीं करना पड़ता है। कॉम्प्लेक्स मोडल सबसे अच्छा उदाहरण हैं, आप लगभग कभी नहीं चाहते हैं कि किसी मोडल विंडो में किसी फॉर्म से ईवेंट ट्रिगर बटन तक प्रचारित हो, लेकिन लगभग निश्चित रूप से पारित संदर्भ की आवश्यकता होती है (i18n, थीम, आदि)

मैं कहूंगा कि उपयोगकेस _could_ को ऐप रूट के करीब एक मॉडलप्रोवाइडर के साथ हल किया जा सकता है जो createPortal माध्यम से इतना अधिक है कि घटना प्रसार कुछ भी प्रभावित नहीं करता है, लेकिन यह एक के विपरीत एक कामकाज की तरह महसूस करना शुरू कर देता है अच्छी तरह से डिजाइन की गई वास्तुकला। यह पुस्तकालय प्रदान किए गए मोडल को उपयोगकर्ताओं के लिए अधिक कष्टप्रद बनाता है क्योंकि वे अब स्वयं निहित नहीं हैं।

मैं एपीआई के संदर्भ में जोड़ूंगा, मुझे नहीं लगता कि createPortal दोनों को करना चाहिए, मोडल केस वास्तव में केवल ReactDOM.render (पुराने स्कूल) का उपयोग करना चाहता है क्योंकि यह एक अलग पेड़ के बहुत करीब है _except_ उस संदर्भ प्रसार की अक्सर आवश्यकता होती है

@kib357 पोस्ट किए गए वर्कअराउंड का उपयोग करने के परिणामस्वरूप हमें अपने बाहरी एप्लिकेशन के फ़ोकस प्रबंधन कोड में एक अत्यंत कठिन-से-निदान बग को ठीक करना था।

विशेष रूप से: पोर्टल से बाहर बुदबुदाने से रोकने के लिए सिंथेटिक फ़ोकस ईवेंट पर स्टॉपप्रॉपैगेशन को कॉल करने से स्टॉपप्रॉपैगेशन को #document पर रिएक्ट के कैप्चर किए गए हैंडलर में मूल फ़ोकस ईवेंट पर भी कॉल किया जाता है, जिसका अर्थ है कि यह इसे <body> पर किसी अन्य कैप्चर किए गए हैंडलर के लिए नहीं बनाता है।

पोर्टल्स में नया बुदबुदाती व्यवहार वास्तव में मुझे अल्पसंख्यक मामला जैसा लगता है। वह राय हो या सच्चाई, क्या हम इस मुद्दे पर कुछ ध्यान दे सकते हैं? शायद @gaearon? यह चार महीने का है और असली दर्द दे रहा है। मुझे लगता है कि इसे काफी हद तक एक बग के रूप में वर्णित किया जा सकता है, यह देखते हुए कि यह रिएक्ट 16 में एक ब्रेकिंग एपीआई परिवर्तन है, जिसमें पूरी तरह से सुरक्षित समाधान नहीं है।

@craigkovatch मैं अभी भी उत्सुक हूं कि आप मेरे इनलाइन उदाहरण को कैसे हल करेंगे। मान लें कि पॉपअप बॉक्स के आकार को नीचे धकेल रहा है। किसी चीज़ को इनलाइन करना महत्वपूर्ण है क्योंकि यह अपने आकार को देखते हुए लेआउट में किसी चीज़ को नीचे धकेल रहा है। यह सिर्फ ऊपर मंडरा नहीं सकता।

आप संभावित रूप से पॉपओवर को माप सकते हैं, एक ही आकार के साथ एक खाली प्लेसहोल्डर डालें और इसे शीर्ष पर संरेखित करने का प्रयास करें लेकिन लोग ऐसा नहीं करते हैं।

तो अगर आपके पॉपओवर को बटन के ठीक बगल में सामग्री का विस्तार करने की आवश्यकता है, तो आप इसे कैसे हल करेंगे? मुझे संदेह है कि वहां काम करने वाला पैटर्न दोनों मामलों में काम करेगा और हमें केवल एक पैटर्न की सिफारिश करनी चाहिए।

मुझे लगता है कि सामान्य तौर पर यह वह पैटर्न है जो दोनों परिदृश्यों में काम करता है:

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}
    </>;
  }
}

यदि फ्लाईआउट एक पोर्टल है, तो यह काम करता है और पोर्टल पर होवर करते समय इसे घटनाओं पर कोई माउस नहीं मिलता है। लेकिन इससे भी महत्वपूर्ण बात यह है कि यह तब भी काम करता है जब यह एक पोर्टल नहीं है, और इसके लिए एक इनलाइन फ्लाईआउट होना आवश्यक है। कोई स्टॉपप्रॉपैगेशन की आवश्यकता नहीं है।

तो इस पैटर्न के बारे में ऐसा क्या है जो आपके उपयोग के मामले में काम नहीं करता है?

@sebmarkbage हम एक पूरी तरह से अलग फैशन में पोर्टल्स का उपयोग कर रहे हैं, एक कंटेनर में प्रस्तुत करना जो <body> के अंतिम बच्चे के रूप में घुड़सवार होता है जिसे कभी-कभी जेड-इंडेक्स के साथ रखा जाता है। रिएक्ट प्रलेखन से पता चलता है कि यह डिजाइन के इरादे के करीब है; यानी डीओएम में एक पूरी तरह से अलग जगह में प्रस्तुत करना। मुझे ऐसा नहीं लगता है कि हमारे उपयोग के मामले इस धागे पर चर्चा के लिए पर्याप्त समान हैं। लेकिन अगर आप एक साथ विचार-मंथन/समस्या निवारण करना चाहते हैं, तो मुझे किसी अन्य मंच पर आगे चर्चा करने में खुशी होगी।

नहीं, मेरा उपयोग मामला दोनों है । कभी एक तो कभी दूसरी। इसलिए यह प्रासंगिक है।

<Flyout /> शरीर के अंतिम बच्चे में प्रस्तुत करना चुन सकता है या नहीं, लेकिन जब तक आप पोर्टल को उसके बच्चे के बजाय होवर किए गए घटक के भाई के लिए फहराते हैं, तो आपका परिदृश्य काम करता है।

मुझे लगता है कि एक व्यावहारिक परिदृश्य है जहां यह असुविधाजनक है और आप चीजों को गहराई से नेस्टेड घटकों से टेलीपोर्ट करने का एक तरीका चाहते हैं लेकिन उस परिदृश्य में आप शायद मध्यवर्ती बिंदु से संदर्भ होने के संदर्भ में ठीक हैं। लेकिन मैं उन्हें दो अलग-अलग मुद्दों के रूप में सोचता हूं।

हो सकता है कि हमें उसके लिए एक स्लॉट एपीआई की आवश्यकता हो।

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" />
    </>;
  }
}

तब पोर्टल को बार का संदर्भ मिलेगा, डीपकंपोनेंट का नहीं। प्रसंग और ईवेंट बबलिंग फिर भी वही ट्री पथ साझा करते हैं।

@sebmarkbage मोडल केस को आमतौर पर उस बिंदु से संदर्भ की आवश्यकता होती है जो इसे प्रस्तुत किया जाता है। यह मेरे विचार से एक मामले का थोड़ा अनूठा है, घटक उस चीज़ का तार्किक बच्चा है जिसने इसे प्रस्तुत किया लेकिन _not_ एक संरचनात्मक एक (बेहतर शब्द की कमी के लिए), उदाहरण के लिए आप आमतौर पर फॉर्म संदर्भ (रिले, फॉर्मिक, रेडक्स फॉर्म) जैसी चीजें चाहते हैं , जो भी हो) लेकिन डीओएम घटनाओं से गुजरने के लिए नहीं। कोई भी इस तरह के मॉडलों को उनके ट्रिगर्स के बगल में पेड़ों में काफी गहराई तक प्रदान करता है, इसलिए वे घटक और पुन: प्रयोज्य रहते हैं, इसलिए भी कि वे संरचनात्मक रूप से वहां से संबंधित हैं

मुझे लगता है कि यह मामला आम तौर पर फ्लाईआउट/ड्रॉपडाउन केस क्रिएटपोर्टल सर्व करता है। टीबीसी मुझे लगता है कि पोर्टल्स का बबलिंग व्यवहार अच्छा है, लेकिन मोडल के लिए नहीं। मुझे यह भी लगता है कि यह संदर्भ और किसी प्रकार के मॉडलप्रोवाइडर के साथ उचित रूप से अच्छी तरह से संभाला जा सकता है, लेकिन यह विशेष रूप से पुस्तकालयों के लिए थोड़ा परेशान है।

जब तक आप पोर्टल को उसके बच्चे के बजाय होवर किए गए घटक के भाई के सामने फहराते हैं, तब तक आपका परिदृश्य काम करता है।

मुझे यकीन नहीं है कि मैं अनुसरण करता हूं। एक अनपेक्षित DOM ट्री के माध्यम से बुदबुदाते हुए keyDown ईवेंट की समस्या अभी भी है।

@jquense ध्यान दें कि मेरे उदाहरण में स्लॉट अभी भी बार घटक के भीतर है, इसलिए इसे <Form><Bar /></Form> जैसे फॉर्म से इसका संदर्भ मिलेगा।

भले ही पोर्टल दस्तावेज़ के मुख्य भाग में रेंडर किया गया हो.

तो यह दो संकेतों (पोर्टलिंग) की तरह है: गहरा -> बार का सहोदर -> दस्तावेज़ निकाय।

तो पोर्टल का संदर्भ अभी भी प्रपत्र का संदर्भ है, और ऐसा ही ईवेंट बुदबुदाती श्रृंखला है, लेकिन न तो होवर की गई चीज़ के संदर्भ में है।

हाँ क्षमा करें चूक गए अगर मैं इसे ठीक से पढ़ रहा हूँ, तो भी आप <Slot> ऊपर बबलिंग करेंगे? यह निश्चित रूप से बेहतर है, हालांकि मुझे लगता है कि मॉडल संवाद मामले में शायद कोई _any_ बुलबुला नहीं चाहता है। स्क्रीन रीडर के संदर्भ में सोचने की तरह, आप चाहते हैं कि मोडल के बाहर सब कुछ उल्टा हो, जबकि यह ऊपर है। मुझे नहीं पता, मुझे लगता है कि उस मामले के लिए बुलबुला एक गोचा है, कोई भी एक संवाद के अंदर एक क्लिक को कहीं भी बुलबुला करने की उम्मीद नहीं करेगा।

हो सकता है कि यहां समस्या पोर्टल नहीं है, लेकिन पेड़ों के बीच संदर्भ साझा करने का कोई अच्छा तरीका नहीं है? संदर्भ चीज़ का एक हिस्सा ReactDOM.render मोडल के लिए वास्तव में ठीक है, और शायद इसके बारे में सोचने का अधिक "सही" तरीका है ...

यहां मेरी सोच यह है कि कुछ बुदबुदाती है क्योंकि यह अभी भी मोडल से डिव से बॉडी तक डॉक्यूमेंट से विंडो तक जाती है। और अवधारणात्मक रूप से फ्रेम से बाहर युक्त खिड़की तक और इसी तरह।

यह एआरटी या जीएल प्रदान की गई सामग्री (और कुछ हद तक रिएक्ट नेटिव) जैसी किसी चीज़ में सैद्धांतिक नहीं है, जहाँ से उन शब्दार्थों को प्राप्त करने के लिए कोई मौजूदा बैकिंग ट्री नहीं हो सकता है। तो यह कहने का एक तरीका होना चाहिए कि

कुछ ऐप्स में मोडल में मोडल होते हैं। उदाहरण के लिए एफबी में चैट विंडो है जो एक मोडल से ऊपर हो सकती है या एक मोडल चैट विंडो का हिस्सा हो सकता है। तो यहां तक ​​​​कि एक मॉडल का भी कुछ संदर्भ होता है कि वह पेड़ में कहां है। यह कभी भी पूरी तरह से स्टैंडअलोन नहीं होता है।

इसका मतलब यह नहीं है कि हमारे पास ईवेंट बबलिंग और संदर्भ के लिए दो अलग-अलग शब्दार्थ नहीं हो सकते हैं। वे दोनों इस बारे में स्पष्ट हैं और आप एक के बिना दूसरे आदि को पोर्टल कर सकते हैं।

गारंटी है कि वे दोनों एक ही पथ का अनुसरण करते हैं, वास्तव में शक्तिशाली है, हालांकि इसका मतलब है कि घटना बबलिंग को पूरी तरह से उपयोगकर्ता अंतरिक्ष घटनाओं के लिए ब्राउज़र के समान ही लागू किया जा सकता है।

उदाहरण के लिए यह आज विभिन्न Redux संदर्भों के साथ होता है। कल्पना कीजिए कि this.context.dispatch("Hover") एक यूजर स्पेस इवेंट बबलिंग है। हम संदर्भ के हिस्से के रूप में रिएक्ट घटनाओं को भी लागू कर सकते हैं। यह सोचना उचित है कि मैं इसे उसी तरह उपयोग कर सकता हूं, और हर तरह से अभी, आप कर सकते हैं। मुझे लगता है कि अगर हमने इन दो संदर्भों को फोर्क किया है, तो हम शायद एक और उपयोगकर्ता स्पेस संदर्भ एपीआई के साथ समाप्त हो जाएंगे जो सामान्य संदर्भ के समानांतर डीओएम संरचना का पालन करता है - अगर वे वास्तव में इतने अलग हैं।

तो इस तरह से मैं इसके खिलाफ थोड़ा जोर दे रहा हूं यह देखने के लिए कि क्या स्लॉट चीज पर्याप्त हो सकती है, क्योंकि ए) आपको इस बारे में स्पष्ट होना चाहिए कि वैसे भी कौन सा संदर्भ बुलबुला होता है। बी) यह दुनिया को फोर्क करने और दो संपूर्ण संदर्भ प्रणालियों से बचने से बच सकता है।

विशेष रूप से: पोर्टल से बाहर बुदबुदाने से रोकने के लिए सिंथेटिक फ़ोकस ईवेंट पर स्टॉपप्रॉपैगेशन को कॉल करने से स्टॉपप्रॉपैगेशन को #दस्तावेज़ पर रिएक्ट के कैप्चर किए गए हैंडलर में मूल फ़ोकस ईवेंट पर भी कॉल किया जाता है, जिसका अर्थ है कि यह इसे किसी अन्य कैप्चर किए गए हैंडलर के लिए नहीं बनाता है

. हमने अपने हैंडलर को #दस्तावेज़ तक ले जाकर ठीक किया, लेकिन हमने विशेष रूप से अतीत में ऐसा करने से परहेज किया था ताकि रिएक्ट के पैर की उंगलियों पर कदम न रखें।

@craigkovatch , क्या आपने दस्तावेज़ पर onFocusCapture ईवेंट का उपयोग किया था? मेरे कामकाज में कैप्चर की गई घटनाओं को रोका नहीं जाना चाहिए। क्या आप इस बारे में अधिक विस्तृत उदाहरण प्रदान कर सकते हैं कि यह कैसा था और आपने अपनी समस्या को हल करने के लिए क्या किया है?
साथ ही, मुझे लगता है कि मेरे कोड में blur ईवेंट को रोकने में कोई समस्या है - इसे रोका नहीं जाना चाहिए। इसलिए, मैं इस प्रश्न की गहराई से जाँच करूँगा और अधिक विश्वसनीय समाधान खोजने का प्रयास करूँगा।

@ kib357 मैं सुझाव नहीं दे रहा हूं कि आपके कामकाज में कोई समस्या है, मुझे लगता है कि वहां रिएक्ट में एक अलग बग है (यानी बुदबुदाती चरण में सिंथेटिक फोकस घटनाओं पर स्टॉपप्रॉपैगेशन को कॉल करते समय कैप्चर चरण में मूल फोकस ईवेंट के प्रचार को रद्द नहीं करना चाहिए)।

विचाराधीन कोड एक देशी कैप्चर इवेंट श्रोता का उपयोग करता है, अर्थात document.body.addEventListener('focus', handler, true)

@craigkovatch दिलचस्प लगता है, इस तथ्य को देखते हुए कि आपने कैप्चर किए गए हैंडलर का उपयोग किया था। हालाँकि, मुझे कोई विचार नहीं है कि ऐसा क्यों होता है।

तो, दोस्तों, पोर्टल रेंडरिंग का उपयोग करने के लिए हमारे पास दो अलग-अलग परिदृश्य हैं:

1. सीएसएस मुद्दों को रोकने के लिए जैसे अतिप्रवाह: छुपा और आदि साधारण विजेट्स में, जैसे ड्रॉपडाउन बटन या एक-स्तरीय मेनू
2. अधिक शक्तिशाली मामलों के लिए एक नई UX परत बनाने के लिए जैसे:
3. क्रियार्थ द्योतक
4. नेस्टेड मेनू
5. पॉपओवर-साथ-फॉर्म-साथ-ड्रॉपडाउन-... - सभी मामले, जब परतें संयुक्त होती हैं

मुझे लगता है कि वर्तमान createPortal एपीआई केवल पहले परिदृश्य को संतुष्ट करता है। दूसरे के लिए एक नए React.render का उपयोग करने का सुझाव अनुपयोगी है - प्रत्येक परत के लिए इसके सभी प्रदाताओं के साथ एक अलग ऐप बनाना बहुत खराब है।
इस समस्या को हल करने में सहायता के लिए हम कौन-सी अतिरिक्त जानकारी प्रदान कर सकते हैं?
createPortal API में सुझाए गए परम के क्या नुकसान हैं?

@sebmarkbage स्लॉट एपीआई के साथ मेरा तत्काल प्रश्न है: क्या मैं एक ही समय में एक से अधिक SlotContents को एक 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>
  </>
}

हमारे पास इसके साथ एक नया मुद्दा है जिसके लिए मैं पूरी तरह से समाधान खोजने में असमर्थ रहा हूं। ऊपर सुझाए गए "इवेंट ट्रैप" दृष्टिकोण का उपयोग करते हुए, केवल रिएक्ट सिंथेटिक ईवेंट को पोर्टल से बाहर निकलने से रोक दिया जाता है। मूल ईवेंट अभी भी बुलबुला है, और चूंकि हमारा रिएक्ट कोड ज्यादातर-jQuery एप्लिकेशन के अंदर होस्ट किया गया है, वैश्विक jQuery कीडाउन हैंडलर <body> अभी भी ईवेंट प्राप्त करता है।

मैंने इस तरह के एक रेफरी के माध्यम से पोर्टल के अंदर मूल कंटेनर तत्व में एक event.stopPropagation श्रोता जोड़ने का प्रयास किया, लेकिन यह पोर्टल के भीतर सभी सिंथेटिक घटनाओं को पूरी तरह से निष्क्रिय कर देता है - मैंने गलत तरीके से माना कि रिएक्ट का शीर्ष-स्तरीय श्रोता कैप्चर चरण देख रहा था।

सुनिश्चित नहीं है कि संभवतः प्रतिक्रिया में परिवर्तन के अलावा यहां क्या किया जा सकता है।

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 ।

@ कोवेन्स्की मेरी समझ यह थी कि jQuery ने "सिंथेटिक

प्रत्यायोजित घटनाओं के मामले में यही होगा। उदाहरण के लिए, $(document.body).on('click', '.my-selector', e => e.stopPropagation()) ।

देखिए, इसे रिएक्ट में हल किया जा सकता है, अगर कोई मुझे सिर्फ यह विश्वास दिलाता है कि इसे मेरे प्रस्तावित डिजाइन के साथ हल नहीं किया जा सकता है जिसके लिए आपके कोड के कुछ पुनर्गठन की आवश्यकता है। लेकिन मैंने ऐसा कोई कारण नहीं देखा है जो केवल एक त्वरित सुधार समाधान खोजने की कोशिश करने के अलावा नहीं किया जा सकता है।

@sebmarkbage आपका प्रस्ताव केवल तत्काल मालिक को प्रचारित करने वाली घटनाओं के मामले को हल करता है। बाकी पेड़ का क्या?

यहाँ एक उपयोग का मामला है जो मुझे लगता है कि स्लॉट या 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 ने किसी घटक की स्थिति की परवाह किए बिना पदानुक्रम के शीर्ष पर सीधे पहुंच की अनुमति दी, या तो पदानुक्रम के भीतर या एक अलग पैक किए गए ढांचे के हिस्से के रूप में।

तुलनात्मक रूप से, मुझे स्लॉट समाधान के साथ कुछ समस्याएं दिखाई देती हैं:

• समाधान मानता है कि आपके पास पदानुक्रम की स्थिति तक पहुंच है जहां बबल घटनाओं के लिए यह "ठीक" है। यह निश्चित रूप से घटकों और घटक ढांचे के मामले में नहीं है।
• मान लें कि पदानुक्रम के किसी अन्य स्तर पर घटनाओं को बबल करना "ठीक" है।
• इवेंट अभी भी स्लॉट की स्थिति से ऊपर उठेंगे। (जैसा कि @craigkovatch ने उल्लेख किया है)

मेरे पास एक उपयोगकेस भी है (शायद पहले से उल्लिखित लोगों के समान)।

मेरे पास एक सतह है जहां उपयोगकर्ता अपने माउस के साथ "लासो" के साथ चीजों का चयन कर सकते हैं। यह मूल रूप से 100% चौड़ाई/ऊंचाई है और मेरे ऐप की जड़ में है और onMouseDown ईवेंट का उपयोग करें। इस सतह में ऐसे बटन भी होते हैं जो मोडल और ड्रॉपडाउन जैसे पोर्टल खोलते हैं। पोर्टल के अंदर एक माउसडाउन घटना वास्तव में ऐप के रूट पर लैस्सो चयन घटक द्वारा इंटरसेप्ट की जाती है।

मैं समस्या को ठीक करने के लिए कई देखता हूं:

• पोर्टल को रूट लैस्सो घटक से एक कदम ऊपर प्रस्तुत करें, लेकिन यह बहुत सुविधाजनक नहीं है और शायद प्रतिक्रिया-गेटवे जैसे संदर्भ-आधारित lib का सहारा लेने की आवश्यकता होगी? (या शायद स्लॉट सिस्टम का उल्लेख किया गया है)।
• पोर्टल रूट के अंदर मैन्युअल रूप से प्रसार को रोकें, लेकिन ऊपर वर्णित अवांछित दुष्प्रभाव हो सकते हैं
• प्रतिक्रिया पोर्टलों में प्रसार को रोकने की क्षमता (+1 btw)
• पोर्टल से आने पर ईवेंट को फ़िल्टर करें

अभी के लिए मेरा समाधान घटनाओं को फ़िल्टर करना है।

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

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


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

यह स्पष्ट रूप से हम सभी के लिए सबसे अच्छा समाधान नहीं होगा और यदि आपके पास नेस्टेड पोर्टल हैं तो यह बहुत अच्छा नहीं होगा, लेकिन मेरे वर्तमान उपयोगकेस (जो वर्तमान में केवल एक ही है) के लिए यह काम करता है। मैं इसे हल करने के लिए एक नया संदर्भ lib जोड़ना या जटिल रिफैक्टर नहीं करना चाहता हूं। बस अपना समाधान साझा करना चाहता था।

जैसा कि इस धागे में कहीं और बताया गया है, मैं ब्लॉकिंग इवेंट बबलिंग को पूरा करने में सक्षम हूं।

लेकिन एक और कांटेदार मुद्दा जो मैं चला रहा हूं वह onMouseEnter SyntheticEvent है, जो बुलबुला नहीं करता है। बल्कि यह from घटक के सामान्य पैरेंट से to घटक तक जाता है जैसा कि यहां वर्णित onMouseEnter हैंडलर को DOM के ऊपर से नीचे createPortal में घटक तक उसी क्रम में ट्रिगर किया जाएगा, जिससे सभी प्रकार की घटनाओं में आग लग जाएगी। unstable_renderSubtreeIntoContainer साथ कभी नहीं किया। चूंकि onMouseEnter बुलबुला नहीं बनता है, इसलिए इसे पोर्टल स्तर पर अवरुद्ध नहीं किया जा सकता है। (यह unstable_renderSubtreeIntoContainer साथ कोई समस्या नहीं लगती थी क्योंकि onMouseEnter घटना आभासी पदानुक्रम का सम्मान नहीं करती थी और शरीर की सामग्री के माध्यम से अनुक्रम नहीं करती थी, बल्कि सीधे उपट्री में उतरती थी।)

यदि किसी के पास onMouseEnter ईवेंट को DOM पदानुक्रम के शीर्ष से प्रचारित होने से रोकने या सीधे पोर्टल सबट्री में डायवर्ट करने से रोकने के बारे में कोई विचार है, तो कृपया मुझे बताएं।

@JasonGore मैंने इस व्यवहार पर भी ध्यान दिया है।

उदाहरण के लिए।

मेरे पास एक संदर्भ मेनू है जो तब प्रस्तुत किया जाता है जब एक div माउसओवर पर ट्रिगर करता है, तो मैं मेनू में किसी एक आइटम पर क्लिक करके createPortal के साथ एक मॉडल खोलता हूं। जब मैं माउस को ब्राउज़र विंडो से बाहर लाता हूं, तो onMouseLeave ईवेंट संदर्भ मेनू तक फैलता है, संदर्भ मेनू (और इस प्रकार मॉडल) को बंद करता है ...

एक ही मुद्दा था जहां मेरे पास एक सूची आइटम था जिसे मैं पूरी तरह से क्लिक करने योग्य (एक लिंक के रूप में) चाहता था, लेकिन नाम के नीचे लेबल पर एक डिलीट बटन चाहता था जो पुष्टि करने के लिए एक मोडल खोल देगा।

मेरा एकमात्र समाधान मोडल डिव पर बुदबुदाहट को रोकना था जैसे:

// components/Modal.js

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

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

यह हर मोडल पर बुदबुदाहट को रोकेगा, लेकिन मेरे पास ऐसा कोई मामला नहीं है जहां मैं चाहता हूं कि ऐसा हो, इसलिए यह मेरे लिए काम करता है।

क्या इस दृष्टिकोण के साथ संभावित मुद्दे हैं?

@jnsandrew यह न भूलें कि ~ 50 अन्य ईवेंट प्रकार हैं जो बबल

बस इसे मारा। यह मेरे लिए अजीब लगता है कि रिएक्ट अपने तरीके से व्यवहार करेगा जो कि डीओएम इवेंट बबलिंग से अलग है।

इसके लिए +1। हम iframe के अंदर रेंडर करने के लिए React.createPortal का उपयोग कर रहे हैं, (शैलियों और ईवेंट आइसोलेशन दोनों के लिए) और बॉक्स से बाहर होने वाली घटनाओं को रोकने में सक्षम नहीं होना एक बहुत बड़ी बात है।

ऐसा लगता है कि रिएक्ट के बैकलॉग में यह 12वां सबसे अधिक पसंद किया जाने वाला मुद्दा है। कम से कम डॉक्स इसके बारे में खुले हैं https://reactjs.org/docs/portals.html#event -bubbling-through-portals - हालांकि वे डाउनसाइड्स या वर्कअराउंड का उल्लेख नहीं करते हैं और इसके बजाय नोट करते हैं कि यह "अधिक लचीले एब्स्ट्रैक्शन" की अनुमति देता है ":

दस्तावेज़ों को कम से कम यह समझाना चाहिए कि इससे समस्याएं पैदा हो सकती हैं और कामकाज का सुझाव दिया जा सकता है। मेरे मामले में, यह https://github.com/reactjs/react-modal का उपयोग करके एक बहुत ही सरल उपयोग का मामला है: मेरे पास बटन हैं जो ड्रॉपडाउन जैसी चीजें खोलते हैं, और इनके अंदर बटन होते हैं जो मोडल बनाते हैं। मोडल बबल अप टू टॉप बटन पर क्लिक करना, जिससे यह अवांछित सामान करता है। मोडल को एक कोसिव कंपोनेंट में एनकैप्सुलेट किया जाता है और पोर्टल वाले हिस्से को बाहर निकालने से उस एनकैप्सुलेशन को तोड़ देता है, जिससे एक लीकी एब्स्ट्रैक्शन बन जाता है। मोडल खुला होने पर इन बटनों को अक्षम करने के लिए एक वैकल्पिक हल फ़्लैग फ़्लिप करना हो सकता है। और निश्चित रूप से मैं कुछ मामलों में उपरोक्त सुझाए गए प्रचार को भी रोक सकता हूं, शायद मैं ऐसा नहीं करना चाहता हूं।

मुझे यकीन नहीं है कि सामान्य रूप से बुदबुदाहट और कब्जा कितना उपयोगी है (मुझे पता है कि प्रतिक्रिया हुड के नीचे बुदबुदाती पर निर्भर करती है) - उनका निश्चित रूप से एक मंजिला इतिहास है, लेकिन मैं एक कॉलबैक पास करना चाहता हूं या एक अधिक विशिष्ट घटना का प्रचार करना चाहता हूं (उदाहरण के लिए, रेडक्स एक्शन) बबल अप या कैप्चर डाउन की तुलना में, क्योंकि ऐसी चीजें शायद अनावश्यक बिचौलियों के एक समूह के माध्यम से होती हैं। https://css-tricks.com/dangers-stopping-event-propagation/ जैसे लेख हैं और मैं उन ऐप्स पर काम करता हूं जो शरीर के प्रसार पर निर्भर करते हैं, ज्यादातर "बाहर" पर क्लिक करते समय चीजों को बंद करने के लिए, लेकिन मैं इसके बजाय हर चीज पर एक अदृश्य ओवरले लगाएं और उस पर क्लिक करने के बाद उसे बंद कर दें। बेशक, मैं इस तरह के एक अदृश्य ओवरले बनाने के लिए रिएक्ट के पोर्टल का उपयोग नहीं कर सका ...

यहां एक रखरखाव दुःस्वप्न भी है - जैसे ही नई घटनाएं डीओएम में जुड़ जाती हैं, उपरोक्त चर्चा की गई तकनीक के साथ "सीलबंद" कोई भी पोर्टल उन नई घटनाओं को "लीक" करेगा जब तक कि रखरखाव उन्हें (व्यापक) ब्लैकलिस्ट में जोड़ नहीं सकते।

यहां एक प्रमुख डिज़ाइन समस्या है जिसे संबोधित करने की आवश्यकता है। क्रॉस-पोर्टल बबलिंग से ऑप्ट-इन या ऑप्ट-आउट करने की क्षमता अभी भी मेरे लिए सबसे अच्छा एपीआई विकल्प है। इसमें कार्यान्वयन की कठिनाई के बारे में निश्चित नहीं है, लेकिन हम अभी भी एक साल बाद, झांकी में इसके आसपास उत्पादन बग प्राप्त कर रहे हैं।

यह पता लगाने की कोशिश में 2 घंटे बिताएं कि मोडल से मेरा फॉर्म दूसरा फॉर्म क्यों जमा कर रहा था।
अंत में मैंने इसे उस मुद्दे के लिए धन्यवाद दिया!

मैं वास्तव में यह देखने के लिए संघर्ष करता हूं कि onSubmit प्रचार कब आवश्यक हो सकता है। सबसे अधिक संभावना है कि यह हमेशा एक फीचर के बजाय एक बग की तरह होगा।

डॉक्स पर
जबकि पोर्टल के माध्यम से ईवेंट बबलिंग एक बेहतरीन विशेषता है, कभी-कभी आप कुछ ईवेंट प्रचार को रोकना चाह सकते हैं। आप इसे onSubmit={(e) => {e.stopPropagation()}} जोड़कर हासिल कर सकते हैं

इसे भी +1 करें। हम मसौदे दिखाने वाले क्लिक करने योग्य टेक्स्ट के साथ भारी उपयोग कर रहे हैं। और मोडल पर सभी ईवेंट जैसे फ़ोकस, सेलेक्ट, चेंज, कीप्रेस आदि। बस त्रुटियों के साथ ड्राफ्टज का विस्फोट।

आईएमओ, घटना-प्रॉक्सी व्यवहार मौलिक रूप से टूटा हुआ है (और मुझे भी बग भी पैदा कर रहा है), लेकिन मैं मानता हूं कि यह विवादास्पद है। यह धागा बहुत दृढ़ता से सुझाव देता है कि एक ऐसे पोर्टल की आवश्यकता है जो वर्महोल संदर्भ दे लेकिन घटनाओं को नहीं। क्या कोर टीम सहमत है? किसी भी तरह, यहाँ अगला कदम क्या है?

मैं वास्तव में महसूस नहीं कर सकता, पोर्टल से घटनाओं का प्रचार करना इरादा व्यवहार क्यों है? यह पूरी तरह से प्रचार के मुख्य विचार के खिलाफ है। मैंने सोचा था कि इस तरह की चीजों से बचने के लिए पोर्टल्स बिल्कुल बनाए गए थे (जैसे मैनुअल नेस्टिंग, इवेंट प्रचार, आदि)।

मैं पुष्टि कर सकता हूं कि यदि आप पोर्टल को तत्वों के पेड़ के पास रखते हैं, तो यह घटनाओं का प्रचार करेगा:

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 ट्री को बबल करते हैं। रिएक्ट में, इवेंट कंपोनेंट ट्री को बबल करते हैं।

मैं मौजूदा व्यवहार पर काफी हद तक भरोसा करता हूं, जिसका एक उदाहरण पॉपआउट है जिसे नेस्टेड किया जा सकता है; वे सभी overflow: hidden साथ मुद्दों से बचने के लिए पोर्टल हैं, लेकिन पॉपआउट को सही ढंग से व्यवहार करने के लिए मुझे पॉपआउट घटक पर बाहरी क्लिक का पता लगाने की आवश्यकता है (जो कि प्रदान किए गए डीओएम तत्वों के बाहर क्लिक का पता लगाने के लिए अलग है) . बेहतर उदाहरण हो सकते हैं।

मुझे लगता है कि यहां मजबूत चर्चा ने यह स्पष्ट कर दिया है कि दोनों व्यवहारों के अच्छे कारण हैं। क्योंकि createPortal एक "सादे डोम" कंटेनर नोड के अंदर एक प्रतिक्रिया घटक प्रस्तुत करता है, मुझे नहीं लगता कि यह रिएक्ट की सिंथेटिक घटनाओं के लिए एक पोर्टल से सादे-पुराने-डोम पेड़ तक प्रचार करने योग्य होगा।

चूंकि पोर्टल लंबे समय से बंद हैं, इसलिए डिफ़ॉल्ट व्यवहार को "पोर्टल सीमा के आगे प्रचारित न करें" में बदलने में शायद बहुत देर हो चुकी है।

अब तक की सभी चर्चाओं के आधार पर, मेरा सबसे सरल प्रस्ताव तब (अभी भी) है: पोर्टल बनाने के लिए एक वैकल्पिक ध्वज जोड़ें जो पोर्टल सीमा के बाद किसी भी घटना के प्रसार को रोकता है।

कुछ और मजबूत घटनाओं की एक श्वेतसूची प्रदान करने की क्षमता हो सकती है जिसे बाकी को रोकते समय सीमा को "प्रहार" करने की अनुमति दी जानी चाहिए।

@gaearon क्या हम इस बिंदु पर हैं कि रिएक्ट टीम वास्तव में इसे ले सकती है? यह एक शीर्ष -10 मुद्दा है लेकिन हमने काफी समय से इस पर आपसे कुछ नहीं सुना है।

मैं इसमें अपना समर्थन जोड़ना चाहता हूं, और पिछले साल की @sebmarkbage की टिप्पणियों से असहमत

डीओएम में एक स्थान से दूसरे स्थान पर संदर्भ को पोर्टल करने की क्षमता सभी तरह के ओवरले जैसे टूलटिप्स, ड्रॉपडाउन, होवर कार्ड और संवाद को लागू करने के लिए उपयोगी है, जहां ओवरले की सामग्री का वर्णन किया गया है, और इसके संदर्भ में प्रतिपादन, ट्रिगर। चूंकि संदर्भ एक प्रतिक्रिया अवधारणा है, यह तंत्र एक प्रतिक्रिया समस्या को हल करता है। दूसरी ओर, DOM ईवेंट बबलिंग को DOM में एक स्थान से दूसरे स्थान पर पोर्टल करने की क्षमता एक फैंसी ट्रिक है जो आपको यह दिखाने की सुविधा देती है कि DOM संरचना आपके द्वारा स्पष्ट रूप से सेट अप के अलावा अन्य है। यह प्रतिनिधिमंडल के लिए DOM ईवेंट बबलिंग का उपयोग करने में समस्या का समाधान करता है, जब आप DOM के किसी भिन्न भाग को प्रतिनिधि बनाना चाहते हैं। यदि आपके पास प्रतिक्रिया है, तो संभवतः आपको कॉलबैक (या संदर्भ) का उपयोग करना चाहिए, बजाय इसके कि आप ओवरले के अंदर से बाहर की ओर बुदबुदाती हुई DOM घटनाओं पर निर्भर हों। जैसा कि अन्य ने इंगित किया है, शायद ही कभी आप "पहुंचना" चाहते हैं और ओवरले के अंदर होने वाली किसी घटना को जानबूझकर या अनजाने में संभालना चाहते हैं।

DOM इवेंट बबलिंग मुख्य रूप से DOM इवेंट को DOM टारगेट से मिलाने की समस्या को हल करता है। प्रत्येक क्लिक वास्तव में नेस्टेड तत्वों के पूरे सेट पर एक क्लिक है। यह एक उच्च स्तरीय प्रतिनिधिमंडल तंत्र, आईएमओ के रूप में सबसे अच्छा नहीं माना जाता है, और प्रतिक्रिया घटक सीमाओं में प्रतिनिधि के लिए डीओएम घटनाओं का उपयोग करना महान encapsulation नहीं है, जब तक कि घटक छोटे निजी सहायक घटक नहीं होते हैं जो डीओएम के अनुमानित बिट्स को प्रस्तुत करने के लिए उपयोग किए जाते हैं।

event.target === event.currentTarget इस समस्या को हल करने में मेरी मदद करता है। लेकिन यह वास्तव में सिरदर्द है।

unstable_renderSubtreeIntoContainer का उपयोग करने के लिए createPortal unstable_renderSubtreeIntoContainer का उपयोग करके पॉपओवर घटक को माइग्रेट करने का प्रयास करते समय आज मुझे यह थोड़ा सा लगता है। विचाराधीन घटक में ड्रैग करने योग्य तत्व होते हैं और इसे किसी अन्य ड्रैग करने योग्य तत्व के वंशज के रूप में प्रस्तुत किया जाता है। इसका मतलब है कि पैरेंट और पॉपओवर दोनों तत्वों में माउस और टच इवेंट हैंडलर होते हैं, जो दोनों ने पोर्टल के पॉपओवर के साथ इंटरैक्ट करते समय फायरिंग शुरू कर दी थी।

चूंकि unstable_renderSubtreeIntoContainer को बहिष्कृत किया जा रहा है (?) एक वैकल्पिक समाधान आवश्यक है - ऊपर प्रस्तुत कोई भी समाधान व्यवहार्य दीर्घकालिक समाधान प्रतीत नहीं होता है।

अरे! इन सभी सुझावों के लिए धन्यवाद दोस्तों!
इसने मुझे अपनी एक परेशानी को ठीक करने में मदद की।
क्या आप रिएक्ट टीम के महत्व और क्षमताओं के बारे में महान और सूचनात्मक लेख पढ़ना चाहेंगे? मुझे लगता है कि यह उन सभी के लिए उपयोगी होगा जो विकास में रुचि रखते हैं। आपको कामयाबी मिले!

आईएमओ यह अधिक बार होता है कि आप एक पोर्टल चाहते हैं जो आपको संदर्भ तक पहुंच प्रदान करे, लेकिन घटनाओं को बबल अप न करे। वापस जब हमने एंगुलर 1.x का उपयोग किया, तो हमने अपनी खुद की पॉपअप सेवा लिखी जो $scope और एक टेम्प्लेट स्ट्रिंग लेगी, और उस टेम्प्लेट को संकलित / प्रस्तुत करेगी और इसे बॉडी में जोड़ देगी। हमने उस सेवा के साथ अपने सभी एप्लिकेशन के पॉपअप/मोडल/ड्रॉपडाउन लागू किए, और एक बार भी हमने ईवेंट बबलिंग की कमी को याद नहीं किया।

stopPropagation() वर्कअराउंड window पर मूल ईवेंट श्रोताओं को ट्रिगर होने से रोकने के लिए प्रतीत होता है (हमारे मामले में react-dnd-html5-backend द्वारा जोड़ा गया)।

यहाँ इस मुद्दे का एक न्यूनतम रेप्रो है: https://codepen.io/mogel/pen/xxKRPbQ

यदि पोर्टल पर सिंथेटिक बबलिंग से बचने का कोई तरीका प्रदान करने की कोई योजना नहीं है, तो शायद किसी के पास ऐसा समाधान है जो मूल ईवेंट बबलिंग को नहीं तोड़ता है?

स्टॉपप्रॉपैगेशन () वर्कअराउंड विंडो पर देशी ईवेंट श्रोताओं को ट्रिगर होने से रोकने के लिए प्रकट होता है

सही। :(

यदि पोर्टल पर सिंथेटिक बुलबुले से बचने का कोई तरीका उपलब्ध कराने की कोई योजना नहीं है

कोर टीम की चुप्पी के बावजूद, मैं, और इस सूत्र पर कई अन्य, _वास्तव में आशा करते हैं कि ऐसी योजनाएं हैं।

शायद किसी के पास वर्कअराउंड है जो मूल घटना बुलबुले को नहीं तोड़ता है?

मेरी टीम ने इस ज्वलंत मुद्दे के कारण पोर्टलों को पूरी तरह से प्रतिबंधित कर दिया है। हम एक कंटेनर में एक हुक के साथ पैन प्रस्तुत करते हैं जो ऐप के अन्य संदर्भों में रहता है, इसलिए आपको रूट स्तर के संदर्भ मुफ्त में मिलते हैं; कोई अन्य जिसे हम मैन्युअल रूप से पार करते हैं। महान नहीं, लेकिन व्यर्थ व्हेक-ए-मोल ईवेंट हैंडलर से बेहतर।

कोर टीम के किसी व्यक्ति द्वारा अंतिम प्रतिक्रिया दिए हुए 17 महीने हो चुके हैं। हो सकता है कि कोई पिंग इस मुद्दे पर कुछ ध्यान दे :) @sebmarkbage या @gaearon

मेरी टीम ने इस ज्वलंत मुद्दे के कारण पोर्टलों को पूरी तरह से प्रतिबंधित कर दिया है। हम एक कंटेनर में एक हुक के साथ पैन प्रस्तुत करते हैं जो ऐप के अन्य संदर्भों में रहता है, इसलिए आपको रूट स्तर के संदर्भ मुफ्त में मिलते हैं; कोई अन्य जिसे हम मैन्युअल रूप से पार करते हैं। महान नहीं, लेकिन व्यर्थ व्हेक-ए-मोल ईवेंट हैंडलर से बेहतर।

मैं कैस्केडिंग प्रॉप्स पर भरोसा किए बिना प्रोप के माध्यम से संदर्भ को "नकली पोर्टल" में पारित करने के लिए किसी भी सामान्य दृष्टिकोण के बारे में नहीं सोच सकता :(

अनगिनत बग थे जिन्हें मैंने https://github.com/reakit/reakit पर पकड़ा था जो इस मुद्दे से संबंधित थे। मैं रिएक्ट पोर्टल का बहुत उपयोग करता हूं और मैं एक भी मामले के बारे में नहीं सोच सकता जहां मैं पोर्टल से उनके मूल घटकों के लिए बबलिंग इवेंट चाहता था।

मेरा कामकाज या तो मेरे मूल ईवेंट हैंडलर के अंदर इसकी जांच कर रहा है:

event.currentTarget.contains(event.target);

या इसके बजाय मूल घटनाओं का उपयोग करना:

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

मैं पुस्तकालय में आंतरिक रूप से उन दृष्टिकोणों का उपयोग करता हूं। लेकिन उनमें से कोई भी आदर्श नहीं है। और, चूंकि यह एक ओपन सोर्स कंपोनेंट लाइब्रेरी है, इसलिए मैं यह नियंत्रित नहीं कर सकता कि लोग इवेंट हैंडलर्स को कंपोनेंट्स में कैसे पास करते हैं।

ईवेंट बबलिंग को अक्षम करने का एक विकल्प उन सभी समस्याओं का समाधान करेगा।

मैंने एक साथ अर्ध-समाधान हैक किया जो window पर घटना के क्लोन को पुन: ट्रिगर करते समय रिएक्ट बबलिंग को अवरुद्ध करता है। ऐसा लगता है कि यह OSX पर क्रोम, फ़ायरफ़ॉक्स और सफारी में काम करता है, लेकिन event.target को मैन्युअल रूप से सेट करने की अनुमति नहीं देने के कारण IE11 को छोड़ दिया गया है। अब तक यह केवल माउस, पॉइंटर, कीबोर्ड और व्हील इवेंट्स की परवाह करता है। सुनिश्चित नहीं है कि ड्रैग इवेंट क्लोन करना संभव होगा या नहीं।

दुर्भाग्य से यह हमारे कोडबेस में प्रयोग करने योग्य नहीं है क्योंकि हमें IE11 समर्थन की आवश्यकता है, लेकिन हो सकता है कि कोई और इसे अपने उपयोग के लिए अनुकूलित कर सके।

यह विशेष रूप से दिमागी दबदबा बनाता है, यह है कि 'डिफ़ॉल्ट' व्यवहार बुलबुले _down_ घटक पेड़ फिर से। निम्नलिखित पेड़ लें:

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

मैं घंटों से अपने बालों को खींच रहा हूं, कि घटकों के इस सटीक संयोजन के साथ मेरे फॉर्म का onSubmit कभी क्यों नहीं कहा जाता है - भले ही मैं सबमिट बटन पर क्लिक करता हूं या फॉर्म के अंदर इनपुट फ़ील्ड में एंटर दबाता हूं।

अंत में, मुझे पता चला कि यह इसलिए है क्योंकि रिएक्ट राउटर Link घटक में onClick कार्यान्वयन है जो ब्राउज़र को पुनः लोड होने से रोकने के लिए e.preventDefault() करता है। हालांकि, यह सबमिट बटन पर क्लिक के डिफ़ॉल्ट व्यवहार को अवरुद्ध करने का दुर्भाग्यपूर्ण दुष्प्रभाव है, जो फ़ॉर्म सबमिट करने के लिए होता है। तो आज मैंने जो सीखा वह है ऑनसबमिट को वास्तव में ब्राउज़र द्वारा सबमिट बटन दबाने के लिए एक डिफ़ॉल्ट क्रिया के रूप में कहा जाता है। यहां तक ​​​​कि जब आप एंटर दबाते हैं, तो यह सबमिट बटन पर एक क्लिक ट्रिगर करता है, इस प्रकार फॉर्म सबमिट को ट्रिगर करता है।

लेकिन आप देखते हैं कि कैसे ईवेंट बबलिंग ऑर्डर इसे वास्तव में अजीब बनाता है।

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 में लपेटने का सामान्य रूप से उपयोग किया जाने वाला समाधान था। लेकिन मेरा कहना है कि मैंने इस मुद्दे को ट्रैक करने में बहुत समय गंवा दिया क्योंकि व्यवहार वास्तव में अनजान है।

हाँ - प्रत्येक _समस्या के व्यक्तिगत उदाहरण_ का एक ही आसान समाधान है, _एक बार जब आपने बग का अनुभव किया और इसे सही ढंग से पहचाना_। यह विफलता का एक बहुत ही खड़ी दीवार वाला गड्ढा है जिसे रिएक्ट टीम ने यहां उकेरा है, और उनसे इसकी कोई पावती नहीं सुनना निराशाजनक है।

मैंने एक और समस्या को डीबग करने का प्रयास करते हुए कई दिन बिताए हैं, जिसमें mouseenter अप्रत्याशित रूप से पोर्टल्स से बाहर आ रहा है। यहां तक ​​​​कि पोर्टल के डिव पर onMouseEnter={e => e.stopPropagation()} , ईवेंट अभी भी स्वामित्व वाले बटन के लिए बुदबुदा रहे हैं, जैसे कि https://github.com/facebook/react/issues/11387#issuecomment -340009465 (पहला) इस मुद्दे पर टिप्पणी)। mouseenter / mouseleave पहले स्थान पर बुलबुला नहीं होना चाहिए ...

शायद अजनबी भी, जब मैं एक पोर्टल से एक बटन पर mouseenter सिंथेटिक ईवेंट बबल देखता हूं, तो e.nativeEvent.type mouseout । प्रतिक्रिया एक बुदबुदाती मूल घटना के आधार पर एक गैर-बुदबुदाती सिंथेटिक घटना को ट्रिगर कर रही है - और सिंथेटिक घटना पर stopPropagation कहे जाने के बावजूद।

@gaearon @trueadm इस मुद्दे ने दो वर्षों से लगातार, भारी निराशा पैदा की है। यह धागा प्रतिक्रिया पर शीर्ष सक्रिय मुद्दों में से एक है। कृपया , क्या टीम का कोई व्यक्ति यहां योगदान दे सकता है ?

मेरे मामले में एक बटन पर क्लिक करके विंडो घटक खोलने से विंडो गायब हो गई क्योंकि विंडो पर क्लिक करने से बटन पर क्लिक हुआ जिससे राज्य परिवर्तन हुआ

मैं प्रतिक्रिया के साथ नया हूं, मैं ज्यादातर एक jQuery और वेनिला जेएस का उपयोग करता हूं लेकिन यह दिमाग उड़ाने वाला बग है। ऐसे 1% मामले हो सकते हैं जब इस व्यवहार की अपेक्षा की जाएगी ...

मुझे @diegohaz से दो समाधान पसंद हैं , लेकिन मुझे अभी भी लगता है कि createPortal ईवेंट बबलिंग को रोकने का विकल्प होना चाहिए।

मेरा विशेष उपयोग मामला टूलटिप के onMouseLeave और onMouseEnter हैंडलर्स के साथ था जो उसके बच्चे के पोर्टल वंशज द्वारा ट्रिगर किया जा रहा था - जो वांछित नहीं था। मूल घटनाओं ने पोर्टल वंशजों को अनदेखा करके इसे ठीक किया क्योंकि वे डोम वंशज नहीं हैं।

पोर्टल्स में बबलिंग रोकने के विकल्प के लिए +1। यह सुझाव दिया गया था कि पोर्टल को केवल एक भाई (बच्चे के बजाय) के रूप में उस घटक में रखा जाए जहां घटना श्रोता उत्पन्न हो रहा है, लेकिन मुझे लगता है कि यह कई उपयोग मामलों (मेरे सहित) में काम नहीं करता है।

अंत में ऐसा लगता है कि ReactDOM.unstable_renderSubtreeIntoContainer को हटा दिया जाएगा , जिसका अर्थ है कि इस मुद्दे के लिए जल्द ही कोई उचित समाधान नहीं बचेगा...

^ हमारी मदद करें @trueadm -nobi आप ही हमारी एकमात्र उम्मीद हैं

ऐसा लगता है कि उन्हें GitHub पर पिंग करने से काम नहीं चलता
शायद एक सक्रिय ट्विटर अकाउंट वाला कोई व्यक्ति इस बारे में ट्वीट कर सकता है, योगदानकर्ताओं में से एक को टैग कर सकता है?

इस मुद्दे के लिए मेरा +1 जोड़ना। नोटियन में, हम वर्तमान में एक कस्टम पोर्टल कार्यान्वयन का उपयोग करते हैं जो React.createPortal , और हम अपने संदर्भ प्रदाताओं को मैन्युअल रूप से नए ट्री पर अग्रेषित करते हैं। मैंने React.createPortal अपनाने की कोशिश की लेकिन अप्रत्याशित बुदबुदाती व्यवहार से अवरुद्ध हो गया:

@sebmarkbage का <Portal> को <MenuItem> घटक के बाहर ले जाने का सुझाव केवल नेस्टिंग स्तर के लिए समस्या का समाधान करता है। समस्या बनी रहती है यदि आपके पास एकाधिक नेस्टेड (उदाहरण) मेनू आइटम हैं जो उप-मेनू को पोर्टल से बाहर करते हैं।

इस समस्या को स्वचालित रूप से पुराना के रूप में चिह्नित कर दिया गया है। यदि यह समस्या अभी भी आपको प्रभावित कर रही है, तो कृपया कोई टिप्पणी छोड़ें (उदाहरण के लिए, "टक्कर"), और हम इसे खुला रखेंगे। हमें खेद है कि हम अभी तक इसे प्राथमिकता नहीं दे पाए हैं। यदि आपके पास कोई नई अतिरिक्त जानकारी है, तो कृपया उसे अपनी टिप्पणी के साथ शामिल करें!

टक्कर।

डैन ने संबंधित मुद्दे पर एक टिप्पणी छोड़ी:

@mogelbrod मेरे पास वर्तमान में उसमें जोड़ने के लिए कुछ भी नहीं है, लेकिन ऐसा कुछ ( #11387 (टिप्पणी) ) मुझे उचित लगता है यदि आप किसी मौजूदा घटक को माइग्रेट कर रहे हैं।

इसी अंक में डैन द्वारा फॉलोअप :

कामकाज के संदर्भ के लिए धन्यवाद। चूंकि आपके पास पहले से ही वह डोमेन ज्ञान है, इसलिए सबसे अच्छा अगला कदम शायद आपके इच्छित व्यवहार और आपके द्वारा चुने गए विकल्पों के लिए एक आरएफसी लिखना है: https://github.com/reactjs/rfcs। ध्यान रखें कि "चलो बस इसे बदल दें" कहने वाला RFC मददगार होने की संभावना नहीं है। एक अच्छा RFC लिखने के लिए दोनों को समझना आवश्यक है कि हमारे पास वर्तमान व्यवहार क्यों है, _और_ इसे इस तरह से बदलने की योजना है जो दूसरों पर ध्यान दिए बिना आपके उपयोग के मामलों के अनुकूल हो।

इसके बावजूद , unstable_renderSubtreeIntoContainer समर्थित नहीं है, तो चलिए इन दोनों चर्चाओं को सुलझाते हैं। हम इसमें कॉन्टेक्स्ट का प्रचार नहीं जोड़ेंगे क्योंकि पूरा एपीआई फ्रोजन है और इसे अपडेट नहीं किया जाएगा।

चर्चा किए गए ध्वज, या शायद किसी अन्य समाधान को जोड़ने का सुझाव देने के लिए हमें निश्चित रूप से एक रिएक्ट आरएफसी प्रकाशित करना चाहिए। क्या किसी को विशेष रूप से एक (शायद @justjake , @craigkovatch , या @jquense) का मसौदा तैयार करने में दिलचस्पी है? यदि नहीं तो मैं देखूंगा कि मैं क्या लेकर आ सकता हूं!

जबकि मैं इस एपीआई को विकसित करने में दिलचस्प हूं, मुझे आरएफसी का मसौदा तैयार करने में कोई दिलचस्पी नहीं है। ज्यादातर बीसी यह काम का एक समूह है और लगभग कोई मौका नहीं है कि इसे स्वीकार किया जाएगा, मुझे नहीं लगता कि कोर टीम वास्तव में आरएफसी पर विचार करती है जो पहले से ही उनके रोडमैप पर नहीं हैं।

@jquense मुझे नहीं लगता कि यह सही है। हां, हम एक आरएफसी को मर्ज करने की संभावना नहीं रखते हैं जो दृष्टि के साथ संरेखित नहीं करता है क्योंकि एक नया एपीआई जोड़ना हमेशा क्रॉस-कटिंग होता है और अन्य सभी नियोजित सुविधाओं को प्रभावित करता है। और यह सही है कि हम अक्सर उन पर टिप्पणी नहीं करते जो काम नहीं करते। हालाँकि, हम उनके माध्यम से पढ़ते हैं, और विशेष रूप से जब हम किसी ऐसे विषय पर पहुंचते हैं जिसमें पारिस्थितिकी तंत्र की अधिक विशेषज्ञता होती है। उदाहरण के लिए, https://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 सभी हमारी सोच में प्रभावशाली रहे हैं, भले ही हमने उन पर स्पष्ट रूप से टिप्पणी नहीं की है।

दूसरे शब्दों में, हम एक सामुदायिक अनुसंधान तंत्र के रूप में आरएफसी से संपर्क करते हैं। @mogelbrod (https://github.com/facebook/react/issues/16721#issuecomment-674748100) की यह टिप्पणी इस बारे में है कि वर्कअराउंड कष्टप्रद क्यों है, ठीक उसी तरह की चीज है जिसे हम RFC में देखना चाहते हैं। मौजूदा समाधानों और उनकी कमियों पर विचार एक ठोस एपीआई सुझाव प्रस्ताव की तुलना में अधिक मूल्यवान हो सकता है।

@gaearon मेरी टिप्पणी यह ​​सुझाव देने के लिए नहीं है कि टीम बाहरी प्रतिक्रिया नहीं सुनती है। आप इसका अच्छा काम करेंगे। मुझे लगता है कि मेरी टिप्पणी सटीक है। _process_ जैसा कि यह RFC रेपो पर चलता है, अन्य लोगों से स्वीकृत RFC का परिणाम नहीं होता है। यह देखते हुए कि किन RFC का विलय किया गया है, यह पूरी तरह से कोर टीम के सदस्य या fb कर्मचारी हैं और कोई नहीं। विशेषताएं जो इसे बनाती हैं, आमतौर पर थोड़ी भिन्न होती हैं और RFC प्रक्रिया में बिल्कुल भी भाग नहीं लेती हैं (उदाहरण के लिए आइसोमॉर्फिक आईडी)।

मुझे यह सुनकर बहुत खुशी हुई कि आप अन्य RFC को देखेंगे और यह कि वे सुविधाओं के लिए डिज़ाइन में योगदान करते हैं, लेकिन "हम RFC के बाहर इन से प्रभावित थे, भले ही हमने उन पर कभी टिप्पणी नहीं की", मुझे लगता है कि मेरी बात को दर्शाता है, नहीं इसे चुनौती दें।

दूसरे शब्दों में, हम एक सामुदायिक अनुसंधान तंत्र के रूप में आरएफसी से संपर्क करते हैं।

यह बहुत ही उचित है, लेकिन आरएफसी रेपो कहता है कि _its_ दृष्टिकोण नहीं है, और यह नहीं कि अन्य लोग आम तौर पर आरएफसी के बारे में कैसे सोचते हैं। आरएफसी प्रक्रिया आम तौर पर टीम और समुदाय के बीच संचार का लिंक और बिंदु है, साथ ही फीचर विचार और प्रक्रिया के मामले में एक समान खेल मैदान भी है।

एक तरफ सामुदायिक शासन के बारे में बड़े बिंदु। लोगों से पूछना, विस्तृत प्रस्तावों को लिखने में समय बिताने के लिए और फिर प्रतिक्रिया टीम से चुप्पी के साथ मिलने पर अन्य बाहरी प्रतिभागियों के लिए उनका बचाव करना निराशाजनक है और सक्रिय रूप से इस धारणा को मजबूत करता है कि एफबी केवल ओएसएस के लिए अपनी जरूरतों की परवाह करता है। जो बदबू आ रही है क्योंकि मुझे पता है कि आप उस तरह से महसूस या डिजाइन नहीं करेंगे।

यदि आरएफसी प्रक्रिया को माना जाता है: "यहां वह जगह है जहां आप अपनी चिंताओं को रेखांकित कर सकते हैं और मामलों का उपयोग कर सकते हैं और हम उन्हें पढ़ेंगे, जब हम इस सुविधा को लागू करने में सक्षम होने के बिंदु पर पहुंच जाएंगे"। ईमानदारी से, यह एक अच्छा तरीका है। मुझे लगता है कि समुदाय को इससे लाभ होगा कि स्पष्ट रूप से लिखा जा रहा है, अन्यथा पीपीएल उसी स्तर की भागीदारी और भागीदारी को ग्रहण करेगा (और करता है) जो अन्य आरएफसी प्रक्रियाओं में अक्सर होता है और फिर सक्रिय रूप से निराश हो जाता है जब वह बाहर नहीं निकलता है। अन्य योगदानकर्ताओं की तुलना में थोड़ी अधिक अंतर्दृष्टि के साथ भी मुझे निश्चित रूप से वह प्रभाव है।

ज़रूर, मुझे लगता है कि मैं इन सब से सहमत हूँ। मैं इसे मेटा-थ्रेड में नहीं बदलना चाहता, लेकिन केवल यह कह रहा हूं कि चूंकि लोग इस धागे के बारे में सोचते रहते हैं, इसलिए इसे आगे बढ़ाने के दोनों पर चिंता करता है पक्षों को ध्यान में रखता है और समस्या स्थान की गहरी समझ को संकलित करता है । मैं पूरी तरह से समझता हूं कि अगर यह ऐसा कुछ नहीं है जो लोग अपने दांतों को डुबोना चाहते हैं (कुछ हद तक हम आरएफसी पर कैसे प्रतिक्रिया देते हैं), यही कारण है कि मैंने पहले इसका सुझाव नहीं दिया है - लेकिन चूंकि मुझे व्यक्तिगत पिंग मिलते रहते हैं, इसलिए मैं सुझाव देना चाहता था कि किसी ऐसे व्यक्ति के लिए एक विकल्प के रूप में जो प्रेरित है।

काफी उचित, आरएफसी पर मेटा प्राप्त करने के लिए यह सही जगह नहीं है :)

@gaearon यह वर्तमान में रिएक्ट पर खुला छठा सबसे अधिक

मुझे इस मुद्दे पर टिप्पणी करने का खेद है और मैं समुदाय RFC के बारे में अपना सुझाव वापस लेता हूं। तुम सही हो यह शायद एक बुरा विचार है। मुझे यह जोड़ना होगा कि यह मुद्दा बहुत भावनात्मक रूप से चार्ज हो गया है, और एक इंसान के रूप में मुझे व्यक्तिगत रूप से इससे जुड़ना मुश्किल लगता है - भले ही मैं समझता हूं कि यह महत्वपूर्ण है और बहुत से लोग इसके बारे में दृढ़ता से महसूस करते हैं।

मुझे इस धागे की स्थिति पर संक्षेप में उत्तर देना चाहिए।

सबसे पहले, मैं उन लोगों से माफ़ी मांगना चाहता हूं जिन्होंने टिप्पणी की और इस धागे में अनुवर्ती कार्रवाई जारी नहीं रखने से निराश हैं। अगर मैं इस मुद्दे को बाहर से पढ़ रहा होता, तो शायद मेरी धारणा यह होती कि रिएक्ट टीम ने गलती की है, इसे स्वीकार करने के लिए तैयार नहीं है, और एक सरल समाधान पर बैठने को तैयार हैं ("बस एक बूलियन जोड़ें, कितना कठिन हो सकता है यह हो!") दो साल से अधिक के लिए क्योंकि उन्हें समुदाय की परवाह नहीं है। मैं पूरी तरह से समझ सकता हूं कि आप इस निष्कर्ष पर कैसे पहुंच सकते हैं।

मुझे पता है कि यह मुद्दा अत्यधिक उभारा गया है। यह इस सूत्र में कई बार लाया गया है, शायद इस दृष्टिकोण से कि अगर रिएक्ट टीम को पता होता कि यह एक बड़ा दर्द बिंदु है, तो हम इसे जल्द ही संबोधित करेंगे। हम जानते हैं

इस समस्या में वर्कअराउंड हैं - जो इसे सुरक्षा भेद्यता या दुर्घटना के विपरीत बनाता है जिसे तत्काल निपटाया जाना है। हम जानते हैं कि वोकराउंड काम करते हैं (लेकिन आदर्श नहीं हैं और कष्टप्रद हो सकते हैं) क्योंकि हम उनमें से कुछ का उपयोग स्वयं करते हैं, विशेष रूप से उस कोड के आसपास जो रिएक्ट 16 से पहले लिखा गया था। मुझे लगता है कि हम इस बात से सहमत हो सकते हैं कि हालांकि यह मुद्दा निस्संदेह एक बड़े पैमाने पर निराशाजनक रहा है। लोगों की संख्या, यह अभी भी एक दुर्घटना या एक सुरक्षा मुद्दे की तुलना में समस्याओं के एक अलग वर्ग में है जिसका एक ठोस समय सीमा के भीतर जवाब दिया जाना चाहिए।

इसके अतिरिक्त, मैं इस फ्रेमिंग से असहमत हूं कि एक सरल उपाय है जिसे हम कल लागू कर सकते हैं। भले ही हम प्रारंभिक व्यवहार को एक गलती मानते हैं (जिसके बारे में मुझे यकीन नहीं है कि मैं इससे सहमत हूं), इसका मतलब है कि अगले व्यवहार को उपयोग के मामलों की पूरी विविधता को संभालने के लिए बार और भी अधिक है । यदि हम कुछ मामलों को ठीक करते हैं लेकिन दूसरों को तोड़ते हैं, तो हमने कोई प्रगति नहीं की है, और एक टन मंथन किया है। ध्यान रखें कि हम उन मामलों के बारे में नहीं सुनेंगे जहां इस मुद्दे में वर्तमान व्यवहार अच्छा काम करता है। हम इसे तोड़ने के बाद ही इसके बारे में सुनेंगे।

आपको एक उदाहरण देने के लिए, वर्तमान व्यवहार वास्तव में घोषणात्मक रूप से फ़ोकस प्रबंधन उपयोग के मामले में मददगार है, जिस पर हम काफी समय से शोध कर रहे हैं। पोर्टल होने के बावजूद, पार्ट ट्री के संबंध में एक मोडल के "अंदर" होने के रूप में फोकस/धुंधलापन का इलाज करना उपयोगी है। यदि हम इस थ्रेड में सुझाए गए "सरल" createPortal(tree, boolean) प्रस्ताव को शिप करते हैं, तो यह उपयोग मामला काम नहीं करेगा क्योंकि पोर्टल स्वयं "जान" नहीं सकता कि हम कौन सा व्यवहार चाहते हैं। संभावित समाधान में किसी भी अन्वेषण के लिए दर्जनों उपयोग के मामलों पर विचार करने की आवश्यकता होती है और उनमें से कुछ को अभी तक पूरी तरह से समझा नहीं गया है। यह सुनिश्चित करने के लिए किसी बिंदु पर करना आवश्यक है, लेकिन इसे सही करने के लिए यह एक बड़ी समय प्रतिबद्धता भी है, और अब तक हम इस पर ध्यान केंद्रित नहीं कर पाए हैं।

विशेष रूप से घटनाएँ एक कांटेदार क्षेत्र हैं, उदाहरण के लिए हमने अभी-अभी परिवर्तनों का एक समूह

आम तौर पर, हम एक टीम के रूप में कुछ समस्याओं पर गहराई से ध्यान केंद्रित करने की कोशिश करते हैं, न कि कई समस्याओं पर। दुर्भाग्य से, इसका मतलब यह है कि कुछ वैचारिक खामियां और अंतराल वर्षों तक नहीं भरे जा सकते हैं क्योंकि हम अन्य महत्वपूर्ण अंतरालों को ठीक करने के बीच में हैं या कोई वैकल्पिक डिजाइन नहीं है जो समस्या को अच्छे के लिए हल कर सके। मुझे पता है कि यह सुनकर निराशा होती है, और यह इस बात का एक हिस्सा है कि मैं इस धागे से दूर क्यों रहा। कुछ अन्य समान सूत्र समस्याओं और संभावित समाधानों की गहरी व्याख्या में बदल गए हैं, जो मददगार हैं, लेकिन यह ज्यादातर "+1" की बाढ़ में बदल गया है और "सरल" फिक्स के लिए सुझाव हैं, यही वजह है कि यह मुश्किल रहा है इसके साथ सार्थक रूप से जुड़ने के लिए।

मुझे पता है कि यह वह उत्तर नहीं है जिसे लोग सुनना चाहते थे, लेकिन मुझे आशा है कि यह उत्तर न देने से बेहतर है।

एक और बात जो ध्यान देने योग्य है वह यह है कि इस सूत्र में वर्णित कुछ दर्द बिंदुओं को अन्य तरीकों से हल किया जा सकता है। उदाहरण के लिए:

विशेष रूप से: पोर्टल से बाहर बुदबुदाने से रोकने के लिए सिंथेटिक फ़ोकस ईवेंट पर स्टॉपप्रॉपैगेशन को कॉल करने से स्टॉपप्रॉपैगेशन को #दस्तावेज़ पर रिएक्ट के कैप्चर किए गए हैंडलर में मूल फ़ोकस ईवेंट पर भी कॉल किया जाता है, जिसका अर्थ है कि यह इसे किसी अन्य कैप्चर किए गए हैंडलर के लिए नहीं बनाता है

रिएक्ट अब बबलिंग का अनुकरण करने के लिए कैप्चर चरण का उपयोग नहीं करता है, और अब दस्तावेज़ पर होने वाली घटनाओं को भी नहीं सुनता है। इसलिए निराशा को खारिज किए बिना, अन्य परिवर्तनों के आलोक में अब तक जो कुछ भी पोस्ट किया गया है, उसका पुनर्मूल्यांकन करना निश्चित रूप से आवश्यक होगा।

मूल घटनाएं अभी भी बुलबुला हैं, और चूंकि हमारा रिएक्ट कोड ज्यादातर-jQuery एप्लिकेशन के अंदर होस्ट किया गया है, वैश्विक jQuery कीडाउन हैंडलर पर

अभी भी घटना प्राप्त करता है।

इसी तरह, रिएक्ट 17 घटनाओं को जड़ों और पोर्टल कंटेनरों से जोड़ देगा (और वास्तव में उस बिंदु पर मूल प्रसार को रोक देगा) इसलिए मुझे भी हल होने की उम्मीद है।

renderSubtreeIntoContainer हटाए जाने के बारे में बिंदुओं के संबंध में। वस्तुतः ReactDOM.render से इसका एकमात्र अंतर यह है कि यह विरासत के संदर्भ का प्रचार करता है। चूंकि कोई भी रिलीज़ जिसमें renderSubtreeIntoContainer शामिल नहीं होगा, उसमें लीगेसी कॉन्टेक्स्ट भी शामिल नहीं होगा, ReactDOM.render 100% समान विकल्प रहेगा। यह, निश्चित रूप से, व्यापक मुद्दे को हल नहीं करता है, लेकिन मुझे लगता है कि विशेष रूप से renderSubtree साथ चिंता कुछ हद तक गलत है।

@gaearon

renderSubtreeIntoContainer हटाए जाने के बारे में बिंदुओं के संबंध में। वस्तुतः ReactDOM.render से इसका एकमात्र अंतर यह है कि यह विरासत के संदर्भ का प्रचार करता है। चूंकि कोई भी रिलीज़ जिसमें renderSubtreeIntoContainer शामिल नहीं होगा, उसमें लीगेसी कॉन्टेक्स्ट भी शामिल नहीं होगा, ReactDOM.render 100% समान विकल्प रहेगा। यह, निश्चित रूप से, व्यापक मुद्दे को हल नहीं करता है, लेकिन मुझे लगता है कि विशेष रूप से renderSubtree साथ चिंता कुछ हद तक गलत है।

अब जब आपने इसका उल्लेख कर दिया है, तो मुझे आश्चर्य है कि क्या नीचे दिया गया कोड बिना इवेंट बबलिंग के रिएक्ट पोर्टल के लिए एक वैध और सुरक्षित कार्यान्वयन होगा:

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;
}

कुछ परीक्षणों के साथ कोडसैंडबॉक्स: https://codesandbox.io/s/react-portal-with-reactdom-render-m22dj?file=/src/App.js

मॉडर्न कॉन्टेक्स्ट को पास न करने की समस्या अभी भी है लेकिन यह कोई नया मुद्दा नहीं है ( renderSubtree भी इससे प्रभावित होता है)। संदर्भ प्रदाताओं के समूह के साथ अपने पेड़ को घेरने के लिए कामकाज है। कुल मिलाकर यह पेड़ों को घोंसला बनाने के लिए आदर्श नहीं है, इसलिए मैं इस पैटर्न को विरासत मौजूदा कोड परिदृश्यों के अलावा किसी अन्य चीज़ में स्थानांतरित करने की अनुशंसा नहीं करता।

एक बार फिर, @gaearon लिखने के लिए बहुत-बहुत धन्यवाद!

ऐसा लगता है कि टूटे हुए मामलों की सूची + वर्कअराउंड (रिएक्ट v17 के लिए अपडेट किया गया) को एकत्रित करना कोर टीम के बाहर किसी के लिए सबसे अधिक उत्पादक चीज होगी (अगर मैं गलत हूं तो मुझे सुधारें!)।

मैं आने वाले सप्ताहों में डूबा हुआ हूं लेकिन ASAP करने का लक्ष्य रखता हूं। अगर कोई और इसे पहले करने में सक्षम है, या स्निपेट्स के साथ झंकार (जैसे @diegohaz ने अभी किया), तो यह बहुत अच्छा होगा!

मामलों की एक सूची एकत्र करना निश्चित रूप से उपयोगी होगा, हालांकि मैं कहूंगा कि इसमें न केवल टूटे हुए मामलों को शामिल करने की आवश्यकता है, बल्कि ऐसे मामले भी हैं जहां वर्तमान व्यवहार समझ में आता है।

अगर इसमें जोड़ने के लिए कोई सार्वजनिक स्थान है तो मुझे हमारे दोनों ऐप्स और UI लाइब्रेरी लेखक के रूप में उपयोग के मामलों को जोड़ने में खुशी होगी। आम तौर पर मैं डैन से सहमत हूं कि कभी-कभी परेशान होने पर काम करना आसान होता है। उन मामलों के लिए जहां आप रिएक्ट की बुदबुदाहट चाहते हैं, रिएक्ट की मदद के बिना मामले को कवर करना बहुत कठिन है।

मामलों की एक सूची एकत्र करना निश्चित रूप से उपयोगी होगा, हालांकि मैं कहूंगा कि इसमें न केवल टूटे हुए मामलों को शामिल करने की आवश्यकता है, बल्कि ऐसे मामले भी हैं जहां वर्तमान व्यवहार समझ में आता है।

मुझे इन्हें शामिल करने में खुशी होगी अगर कोई मुझे कुछ ओपन सोर्स कोड/निकाले गए कोड पर इंगित कर सकता है जो उस पर निर्भर करता है! जैसा कि आपने पहले उल्लेख किया है, यह खोजना एक चुनौती है क्योंकि केवल वर्तमान व्यवहार के साथ समस्या वाले लोग ही इस मुद्दे पर शामिल होते हैं

अगर इसमें जोड़ने के लिए कोई सार्वजनिक स्थान है तो मुझे हमारे दोनों ऐप्स और UI लाइब्रेरी लेखक के रूप में उपयोग के मामलों को जोड़ने में खुशी होगी। आम तौर पर मैं डैन से सहमत हूं कि कभी-कभी परेशान होने पर काम करना आसान होता है। उन मामलों के लिए जहां आप रिएक्ट की बुदबुदाहट चाहते हैं, रिएक्ट की मदद के बिना मामले को कवर करना बहुत कठिन है।

आपके मन में कोई विशिष्ट स्थान है, या एक कोडसैंडबॉक्स (या jsfiddle, आदि) प्रति केस एक स्टार्टर के रूप में काम करेगा? एक बार जब हम कुछ मामले एकत्र कर लेते हैं तो मैं उन सभी को संकलित करने का प्रयास कर सकता हूं।

मैंने यहां एक सूत्र शुरू किया: https://github.com/facebook/react/issues/19637 । आइए इसे व्यावहारिक उदाहरणों पर केंद्रित रखें, जबकि यह एक सामान्य चर्चा के लिए रहता है।