क्योंकि जब आप रैपर नहीं डालते हैं, तो यह इस पर निर्भर करता है:

return React.DOM.div(...)React.DOM.div(...)

जो वाक्य-विन्यास का कोई मतलब नहीं है। यदि आपको विजुअल मैपिंग की आवश्यकता है तो जेएसएक्स कंपाइलर पेज मदद कर सकता है।

ऐसा कहा जा रहा है, इसके बजाय इसे [div, div] तक डिसुगर करना संभव है। यह कठिन है, कुछ विवादास्पद है और निकट भविष्य में इसे लागू नहीं किया जाएगा।

(मुझे नहीं लगता कि यह विशेष रूप से विवादास्पद है लेकिन यह कोड जटिलता जोड़ता है और अभी तक नहीं किया गया है।)

IIRC @syranide की इस पर कुछ टिप्पणियाँ हैं

@chenglou हेहे ।

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

अधिकांश एक घटक पर लौटने की सादगी का अर्थ है कि आप जो देखते हैं उसके बारे में तर्क करना बहुत आसान है, यदि नहीं, तो <table><TableHeader /></table> वास्तव में कितनी भी पंक्तियों को प्रस्तुत कर सकता है, आपके पास TableHeader निरीक्षण करने के अलावा अन्य जानने का कोई तरीका नहीं है

मुझे लगता है कि कई घटकों को वापस करने में सक्षम होने के कारण केवल "समग्र घटक" से आवश्यक रूप से घटकों को लपेटने की ज़िम्मेदारी चलती है जो "समग्र घटक प्रदान करता है"। घटक "जो समग्र घटक प्रदान करता है" को शायद ही कभी इस बात का ज्ञान होना चाहिए या होना चाहिए कि समग्र घटकों को लपेटना है या नहीं, जबकि बच्चों को अपने माता-पिता के बारे में ज्ञान होने की अधिक संभावना है।

लेकिन शायद यह केवल डेवलपर जिम्मेदारी का मामला है। दोनों के लिए अच्छे उपयोग के मामले हो सकते हैं और हमें केवल अपरिहार्य दुरुपयोग को देखना चाहिए।

@sebmarkbage शायद कुछ टिप्पणियां भी हैं :)

हम शायद कभी भी उस वाक्य रचना को परोक्ष रूप से अनुमति नहीं देंगे। आपको एक रैपर की आवश्यकता होगी जैसे

<>
  <div className="col-md-8">
  </div>
  <div className="cold-md-4">
  </div>
</>

या

[
  <div className="col-md-8">
  </div>,
  <div className="cold-md-4">
  </div>
]

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

लेकिन, वास्तव में, हम अभी इसका समर्थन नहीं करने का एकमात्र कारण यह है कि इसे लागू करना कठिन है। उम्मीद है, हम भविष्य में कभी-कभी इसका समर्थन करने में सक्षम होंगे, लेकिन शायद अल्पकालिक नहीं। माफ़ करना। :/

क्या यह jQuery या अन्य पुस्तकालयों जैसी चीजों को प्रभावित नहीं कर सकता है जो विशिष्ट तत्वों को लक्षित करते हैं, इसलिए यदि आप $('#id-name').children() जैसा कुछ करते हैं, तो निम्न:

<div id="id-name">
  <div>
    <div class="class-name">
    </div>
  </div>
</div>

इस मामले में <div> और <div class="class-name"> का चयन किया जाएगा। (अगर मैं इसे ठीक से समझता हूं)

यह उसी तरह से सीएसएस चयनकर्ताओं को भी प्रभावित करता है जैसे @AdamKyle ने पहले पोस्ट किया था।

इस मुद्दे पर कोई अपडेट?

मेरे घटक ने काम क्यों नहीं किया, यह समझने में कुछ मिनट बिताए। मुझे लगता है कि कहीं नोटिस होना चाहिए, शायद मैं चूक गया? शायद कोशिश करना स्पष्ट रूप से गलत है:

var Optimistic = React.createClass({
  render: function() {
    return ( 
      <h1>{this.props.name} loves React</h1>
      <p>React doesn’t. Idea: sprinkle some divs here and there.</p>
    );
  }
});

React.render(
  <Optimistic name="Peter" />,
  document.getElementById('myContainer')
);

@gabssnake आपको त्रुटि के साथ JSX संकलन त्रुटि मिलनी चाहिए थी "आसन्न XJS तत्वों को एक संलग्न टैग में लपेटा जाना चाहिए"; क्या आपने त्रुटि नहीं देखी या इसकी व्याख्या में यह स्पष्ट नहीं था?

आपके उत्तर @spicyj के लिए धन्यवाद। खैर, मेरा मतलब रिएक्ट डॉक्यूमेंटेशन में एक नोटिस था। हां, कंसोल ने एक त्रुटि दिखाई, लेकिन लपेटने की आवश्यकता मुझे पहले समझ में नहीं आई। इसलिए मैंने खोजा और यहां पहुंचा।

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

बस इतना ही कह रहा हूं.. मैं घटक _but_ से कई बच्चों को वापस करने की वकालत नहीं कर रहा हूं, मैं इसे render* विधियों में करना पसंद करूंगा जो मैं render से निकालता हूं:

  render: function () {
    return (
      <div className={this.getClassName()}
           style={{
             color: this.props.color,
             backgroundColor: this.props.backgroundColor
           }}>
        {condition ?
          this.renderSomething() :
          this.renderOtherThing()
        }
      </div>
    );
  },

  renderSomething() {
    return (
      <>
        <div className='AboutSection-header'>
          <h1>{this.props.title}</h1>
          {this.props.subtitle &&
            <h4>{this.props.subtitle}</h4>
          }
        </div>,

        {hasChildren &&
          <div className='AboutSection-extra'>
            {this.props.children}
          </div>
        }
      </>
    );
  }

लेकिन मुझे शायद चुप रहना चाहिए और key s का उपयोग करना चाहिए।

@gaearon आप पहले से ही ऐसा कर सकते हैं, आपको अभी के लिए एक सरणी वापस करने की आवश्यकता है (जो थोड़ा बोझिल है, हालांकि हाँ) ... buuuuut, आप इसके आसपास काम कर सकते हैं, मैंने अपना खुद <Frag> घटक हैक कर लिया है जिसका एक सरणी में अनुवाद किया गया है (ओवरलोडेड React.render ) ... आप return <NoopComp>...</NoopComp>.props.children भी कर सकते हैं, मुझे लगता है, अगर आप हैक्स से बचना चाहते हैं।

संपादित करें: मेरा बुरा, मैंने React.createElement नहीं React.render ओवरलोड किया।

सरणियों के साथ समस्या यह है कि वे हमारे डिजाइनर की यात्रा करते हैं। अल्पविराम, स्पष्ट कुंजी चाहिए।

@gaearon हाँ, आप अभी के लिए मेरे दो वर्कअराउंड में से किसी एक का उपयोग करके अल्पविराम से बच सकते हैं (यदि आपको या तो स्वीकार्य लगता है) ...

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

@gaearon आह हाँ, मैं अभी के लिए उस चेतावनी को मानसिक रूप से अनदेखा करना चुनता हूं :), यदि आप वास्तव में इससे बचना चाहते हैं, तो आप इससे बचने के लिए <MyComp children={this.renderWhatever()} /> कर सकते हैं ( संपादित करें: हालांकि आप स्पष्ट रूप से इसका उपयोग नहीं कर सकते हैं यदि आपके आस-पास के बच्चे हैं, तो आप कुछ चपटे सहायक का उपयोग कर सकते हैं ... लेकिन हाँ)।

एक और मामला जो मैंने UI किट के साथ चलाया है। जब आप बच्चों को एक निश्चित स्क्रॉल करने योग्य कंटेनर के अंदर रख रहे हैं जैसे:

return (
  <div style={{
    position: fixed
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
    overflow-y: scroll;
  }}>
    {this.props.children}
  </div>
);

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

मेरे पास एक और उपयोग-मामला है जिसका मैंने यहां #3415 पर विस्तार से वर्णन किया है। लेकिन मैं इसे अभी के लिए हल कर सकता हूं और समझ सकता हूं कि इसे लागू करना कठिन और दुर्लभ है।

मुझे प्रतिक्रिया आंतरिक (अभी तक) के बारे में कुछ नहीं पता है, लेकिन मैं सिर्फ एक विचार में फेंक दूंगा कि आप डीओएम में ऐसे आभासी मूल तत्वों/टुकड़ों को कैसे चिह्नित कर सकते हैं: टिप्पणियां। उदाहरण के लिए

<A>
    <B></B>
    <Fragment>
        <C></C>
        <D></D>
    </Fragment>
    <E></E>
</A>

को प्रस्तुत करना होगा

<a>
    <b></b>
    <!--<fragment data-reactid="">-->
        <c></c>
        <d></d>
    <!--</fragment>-->
    <e></e>
</a>

इसका मतलब है कि c और d को sth की संतान माना जाएगा। (बी और ई के साथ विरोध नहीं करने के लिए नेस्टेड प्रतिक्रिया सहित)। मैंने इस तरह की अर्थपूर्ण नौकरियों के लिए अन्य ढांचे "दुरुपयोग" टिप्पणियों को देखा है।

@Prinzhorn मुझे लगता है कि आप रिएक्ट के JSX के साथ DOM आउटपुट को भ्रमित कर रहे होंगे।

यदि यह उपयोगी है: @Prinzhorn का DOM में "टुकड़ा घटकों" को मैप करने के लिए HTML टिप्पणियों का उपयोग करने का सुझाव वही दृष्टिकोण है जो नॉकआउट उपयोग करता है। नॉकआउट इन "आभासी तत्वों" को बुलाता है।

<!-- ko component: "message-editor" -->
<!-- /ko -->

( नॉकआउट डॉक्स से)

इसके अलावा, इसके लिए एक और उपयोग का मामला - फ्लेक्सबॉक्स का उपयोग करते समय अतिरिक्त रैपिंग तत्व समस्याग्रस्त हो सकते हैं।

@aldendaniels बिल्कुल सहमत हैं, मैं पहले से ही फ्लेक्सबॉक्स मुद्दों में भाग चुका हूं।

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

<A>
 <Drop />
 <C><Drop /><Drop /></C>
</A>

ए, बी, सी, और डी स्टेटलेस हैं इसलिए मैंने उन्हें class B {render(){ this.props }} से function B(props){ return [...]; } में बदल दिया।

इस मामले में, माता-पिता के लिए यह बहुत मायने नहीं रखता है कि कई बच्चों का प्रतिपादन किया गया है, यह सिर्फ मेरे सीएसएस से निपटने के लिए है। ऐसी चीजें हैं जो मैं अलग तरीके से करूंगा यदि इन्हें पुन: उपयोग करने की आवश्यकता नहीं है (दूसरे घटक को बी, सी और डी की आवश्यकता है)।

एक विकल्प के रूप में, शायद इसे माता-पिता से सुलझाने का एक तरीका है? मेरे पास कोई विशिष्ट विचार नहीं है कि यह कैसा दिखेगा।

मैंने आज एक परिदृश्य मारा जो मुझे लगता है कि इस सुविधा के लिए एक अच्छा उपयोग मामला है: एक घटक जो एकाधिक <script> तत्वों को प्रस्तुत करता है, जहां यह पृष्ठ के <head> तत्व में प्रस्तुत किया जा सकता है। वहां कोई भी रैपर तत्व खराब होगा।

मेरा परिदृश्य एक घटक रखना चाहता है जो पृष्ठ पर आवश्यक रनटाइम कोड के लिए <script> टैग के साथ-साथ एक और <script> टैग प्रदान करने के लिए ज़िम्मेदार है जो स्थानीयकृत तारों का उपयोग करता है रनटाइम कोड। उदाहरण के लिए:

<html>
    <head>
        <script language="runtime.resources.en-us.js"></script>
        <script language="runtime.js"></script>
    </head>
    <body>
    ...
    </body>
</html>

इस मामले में, मैं कोड को इस प्रकार लिखना चाहता हूं:

var RuntimeScripts = require('./Runtime')
...
return (
    <html>
        <head>
            <RuntimeScripts language="en-us" />
        </head>
    </html>
)
...

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

यहां प्रस्तुत सभी उपयोग-मामलों के लिए मुझे पूरा यकीन है कि आप <BunchOfComponents /> को {getBunchOfComponents()} से बदल सकते हैं और दृश्य आउटपुट समान होगा, बिना घटकों के होने से संबंधित व्यावहारिक और तकनीकी मुद्दों को पेश किए बिना जड़ के रूप में टुकड़े।

@syranide लेकिन हर बार जब कोई घटक बदलता है तो उसके सभी भाई-बहनों को पुनर्गणना की आवश्यकता होती है ...

इसके अलावा यदि आप सादे कॉफ़ीस्क्रिप्ट का उपयोग करते हैं तो एक सरणी वापस करना आसान है, इसलिए कृपया जेएसएक्स प्रतिनिधित्व से कार्यक्षमता को अलग करें।
IOW यदि तत्वों की लौटाई गई सरणी को संभालना आसान है, तो जेएसएक्स को पकड़ने की प्रतीक्षा न करें।

@syranide लेकिन हर बार जब कोई घटक बदलता है तो उसके सभी भाई-बहनों को पुनर्गणना की आवश्यकता होती है ...

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

इसके अलावा यदि आप सादे कॉफ़ीस्क्रिप्ट का उपयोग करते हैं तो एक सरणी वापस करना आसान है, इसलिए कृपया जेएसएक्स प्रतिनिधित्व से कार्यक्षमता को अलग करें।

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

@syranide सबसे बड़ी समस्या यह है कि आप हमेशा रैपिंग का उपयोग नहीं कर सकते हैं
एचटीएमएल में तत्व, जैसे टेबल, सूचियां, फ्लेक्सबॉक्स, हेड ... आसपास काम करना
जो बदसूरत कोड की ओर जाता है।

मैं वर्चुअल रैपर तत्व से पूरी तरह खुश हूं जो केवल प्रस्तुत करता है
टिप्पणियाँ, जैसा कि पहले सुझाव दिया गया था।

शुक्र, मई 29, 2015, 3:56 अपराह्न को एंड्रियास स्वेन्सन नोटिफिकेशन @github.com
लिखा था:

@syranide https://github.com/syranide लेकिन हर बार इनमें से एक
घटक परिवर्तन इसके सभी भाई-बहनों को पुनर्गणना की आवश्यकता है ...

@wmertens https://github.com/wmertens हां, लेकिन कई बार आप करेंगे
वैसे भी है क्योंकि माता-पिता को दूसरे के लिए पुन: प्रस्तुत करने की आवश्यकता होगी
कारण, या केवल इसलिए कि आप वैसे भी प्रॉप्स के माध्यम से डेटा प्राप्त करते हैं। परंतु
हां, यही अंतर है, लेकिन इसका मतलब यह नहीं है कि यह तरीका सही है,
यह एक अनुकूलन है और उन्हें पूरा करने के कई तरीके हैं।

इसके अलावा यदि आप सादे कॉफ़ीस्क्रिप्ट का उपयोग करते हैं तो एक सरणी वापस करना आसान है, इसलिए कृपया
जेएसएक्स प्रतिनिधित्व से कार्यक्षमता को अलग करें।

यह अप्रासंगिक है और यह JSX के साथ कोई समस्या नहीं है। एक बड़ा मुद्दा यह है कि
आप _one . की तकनीकी, व्यावहारिक और सहज धारणा खो देते हैं
घटक = एक तत्व/नोड_. मैं देवों के लिए नहीं बोल सकता, लेकिन मैं नहीं
इसे स्वेच्छा से छोड़ दें, यह एक बहुत ही उपयोगी धारणा है। मुझे यकीन है
समान रूप से अच्छे या बेहतर अनुकूलन हैं जिन्हें डिज़ाइन किया जा सकता है यदि
अनुकूलन ही एकमात्र कारण है जिससे लोग इसे चाहते हैं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/facebook/react/issues/2127#issuecomment -106810565।

fwiw, रिएक्ट में "टुकड़ा" घटक को हैक करना अपेक्षाकृत आसान है जिसे रिएक्ट द्वारा अपने बच्चों की एक सरणी के रूप में माना जाता है। यह कुंजियों को स्वतः उत्पन्न करेगा, लेकिन चूंकि यह घटकों के प्रारंभिक सत्यापन के बाद होता है, यह सामान्य "कोई कुंजी आपूर्ति नहीं" त्रुटि नहीं फेंकेगा।

इसके साथ ही, वह हैक केवल वही हल करता है जो @gaearon ऊपर के बारे में बात कर रहा था - बदसूरत सरणी वाक्यविन्यास/आपके जेएसएक्स में मनमानी कुंजी सेट करने से निपटने के लिए नहीं - और एक घटक की रेंडर विधि की जड़ पर एकाधिक नोड्स वापस करने का मुद्दा नहीं।

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

<Main>
  <Foo />
  <Fragment>
    <Bar />
    <Baz />
  </Fragment>
</Main>

डोम के रूप में समाप्त करने के लिए:

<div>
  <div>Foo</div>
  <div>Bar</div>
  <div>Baz</div>
</div>

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

यह "अनुकूलन" के बारे में नहीं है, या तो, या यहां तक ​​​​कि सरणी वाक्यविन्यास पसंद नहीं करने के बारे में भी नहीं है। जैसा कि कई उपयोगकर्ताओं ने उल्लेख किया है, _wrapper तत्व स्टाइल और लेआउट को गंभीर तरीकों से तोड़ते हैं_। टेबल्स सबसे स्पष्ट हैं, लेकिन फ्लेक्सबॉक्स भी एक प्रमुख मुद्दा है। मेरे पास पहले से ही सीएसएस है जो केवल फ्लेक्स नियमों को रैपर तत्वों पर लागू करता है जो केवल प्रतिक्रिया के कारण मौजूद हैं, और यह बहुत बदसूरत है।

यहां प्रस्तुत सभी उपयोग-मामलों के लिए मुझे पूरा यकीन है कि आप प्रतिस्थापित कर सकते हैं {getBunchOfComponents ()} के साथ और दृश्य आउटपुट समान होगा, बिना रूट के टुकड़ों वाले घटकों से संबंधित व्यावहारिक और तकनीकी मुद्दों को पेश किए बिना।

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

@thomasboyt

संपादित करें: मेरी गलती, मैंने उपरोक्त तालिका-चर्चा के साथ आपके कुछ तर्कों को स्वीकार कर लिया है, मैं काफी हद तक सहमत हूं कि आप जो कह रहे हैं वह मुझे लगता है। लेकिन घटकों के अपारदर्शी होने में अभी भी समस्याएं हैं, इसलिए एक उपयोगी पारदर्शी आवरण के रूप में जो इरादा है वह माता-पिता के लिए अपारदर्शी हो जाता है। कल्पना कीजिए <Wrapper1><Wrapper2>...</Wrapper2></Wrapper1> , Wrapper1 Wrapper2 के बच्चों को नहीं देख सकता। तो शायद wrapMyElements(...) अभी भी एक बेहतर समाधान है (किसी भी अन्य आवश्यक सहायक कार्यक्षमता सहित)।

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

अवयव सिर्फ गूंगा आवरण से अधिक हैं, उनका एक उद्देश्य है। IMHO ऐसा लगता है कि कई तत्वों को वापस करने से कुछ बहुत ही उपयोगी अपेक्षाएँ अवरुद्ध हो जाती हैं। उदाहरण के लिए, React.render को भविष्य में एक साथी मिलेगा जो एक तत्व प्रस्तुत करता है और नोड्स लौटाता है, इसके बजाय अब नोड्स की एक सरणी उत्पन्न करनी होगी।

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

<table>
  <tr>
    <td />
    <td />
    <td />
  </tr>
  <tr>
    <Columns1 />
    <Columns2 />
  </tr>
</table>

इसे देखकर कोई मतलब नहीं है कि तीसरा सेल कहां से आ रहा है? शायद यह वास्तव में गलत है और यह 2 या 4 कोशिकाओं का प्रतिपादन कर रहा है, कौन जानता है, शायद यह वास्तव में गतिशील है और एक प्रोप या बाहरी स्थिति पर निर्भर करता है? इस समस्या के कई रूप हैं जो केवल तब और अधिक बढ़ जाते हैं जब आप अन्य गैर-HTMLDOM फ़्रंटएंड पर विचार करते हैं जिनकी स्पष्ट अपेक्षाएँ हो सकती हैं। एक और बात पर विचार करना है कि तत्व अपारदर्शी हैं, इसलिए यदि आप <tr /> को <MyMagicalTr /> से प्रतिस्थापित करते हैं तो यह व्यक्तिगत कोशिकाओं के साथ बातचीत करने में सक्षम नहीं है या यहां तक ​​​​कि कितने हैं, भले ही <MyMagicalTr /> केवल <MyMagicalTd /> स्वीकार कर सकता है, इसकी कोई गारंटी नहीं है कि यह वास्तव में उनके साथ बातचीत कर सकता है।

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

"इसके लिए डेवलपर्स को अलग-थलग करने पर समझौता करने की आवश्यकता होती है ...", लेकिन यह वास्तव में समस्या है यदि आप मुझसे पूछते हैं, यदि कोई घटक कई तत्वों को वापस कर सकता है तो इसे अब अलग नहीं किया जाता है, इसे प्रतिस्थापित किया जाता है, घटक माता-पिता में लीक हो रहा है।

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

IMHO मुझे {getBunchOfComponents()} के साथ समस्या दिखाई नहीं दे रही है, यह स्पष्ट है, यह हमें अपनी उपयोगी अपेक्षाओं को बनाए रखने की अनुमति देता है। यदि प्रदर्शन एक समस्या है तो बचाव के लिए React.createSmartFragment() (या w/e), एक पारदर्शी सरणी/ऑब्जेक्ट-जैसी प्रकार लेकिन एक जो अपने माता-पिता से स्वतंत्र रूप से अपडेट हो सकती है।

फिर से, रिएक्ट देव प्राधिकरण हैं (मैं नहीं), लेकिन मुझे विभिन्न दुष्प्रभावों पर विचार करते हुए यहां कोई ठोस तर्क नहीं दिखता है। मुझे यह भी यकीन नहीं है कि मैं प्रस्तुत समाधान के साथ एक अच्छा पैटर्न होने के साथ सहमत हूं, भले ही यह समर्थित था।

संपादित करें: स्पष्ट करने के लिए, शायद घटक भविष्य में कई तत्वों को वापस करने में सक्षम हो सकते हैं क्योंकि अन्य स्पष्ट रूप से लाभकारी उपयोग-मामले हैं, विशेष रूप से बच्चों के माध्यम से गुजरने के संदर्भ में (जैसे कि आप @thomasboyt दिखाते हैं), पठनीयता बनाए रखी जाती है।

मुझे लगता है कि इस बातचीत के दार्शनिक पक्ष का जवाब देने से पहले मुझे थोड़ी और कॉफी की आवश्यकता होगी (बहुत अच्छे बिंदुओं के लिए धन्यवाद, @syranide), लेकिन कार्यान्वयन पक्ष पर, मैंने यह देखने के लिए पिछली रात को चारों ओर घूमना शुरू कर दिया था कि कैसे व्यवहार्य इस दायरे में बदलाव है, जो इस स्पाइक की ओर ले जा रहा है: https://github.com/facebook/react/compare/master...thomasboyt:fragment

और यहाँ एक छोटा सा डेमो दिया: http://www.thomasboyt.com/react-fragment-demo/

चीजों के कार्यान्वयन पक्ष पर कुछ अवलोकन:

• आश्चर्य की बात नहीं है, एक सिस्टम को फिर से निकालना बहुत मुश्किल है जो "1 घटक = 1 नोड" से अधिक नोड्स का समर्थन करने की अपेक्षा करता है;)
• मैंने शुरुआत में डीओएम संचालन पक्ष पर टुकड़ों को ट्रैक करने का प्रयास करने के बारे में सोचा, ताकि ReactMultiChild उत्पन्न उत्परिवर्तन निर्देश वही रह सकें और किसी अन्य नोड की तरह टुकड़ों का इलाज कर सकें। मैं नोड गिनती के बारे में राज्य जोड़ने का एक अच्छा तरीका नहीं सोच सका/हालांकि, डीओएम राज्य ट्रैकिंग में कौन से नोड्स टुकड़े हैं। टिप्पणी बाड़ लगाने की तरह कुछ @ प्रिंज़होर्न ने नोट किया काम कर सकता है, लेकिन मैं किसी भी चीज़ से सावधान हूं जिसके लिए सापेक्ष लागत पर विचार करने के लिए डीओएम लुकअप की आवश्यकता होगी।
• उस विचार को त्यागने के साथ, मैंने ReactMultiChild घटक के सभी बच्चों के लिए _nodeCount फ़ील्ड जोड़ा, ताकि यह रूट नोड्स की संख्या को ट्रैक कर सके जिसमें वास्तव में एक टुकड़ा होता है।

समस्या यह है, जबकि प्रारंभिक रेंडर पर केवल एक टुकड़े के बच्चों की गिनती करके ऐसा करना काफी आसान है, बाद के उत्परिवर्तनों पर टुकड़े की नोड गिनती को अद्यतन करना मुश्किल लगता है। यह अभी भी मेरी शाखा पर नहीं किया गया है (देखें https://github.com/thomasboyt/react/issues/2)।

• कई DOM ऑपरेशन तत्वों को जोड़ने/स्थानांतरित करने/निकालने के लिए आंतरिक नोड आईडी द्वारा देखे गए तत्व के मूल नोड तक पहुँचने पर निर्भर करते हैं (देखें https://github.com/thomasboyt/react/issues/3)। चूंकि ReactMultiChild का अपडेट कॉम्पोनेंट चक्र इस आईडी को पास करने के लिए ज़िम्मेदार है, इसलिए इसे निकटतम माता-पिता की तलाश करने के लिए बदला जा सकता है जिसमें डोम नोड है, लेकिन यह महंगा लगता है। वैकल्पिक रूप से, यह संभव हो सकता है कि उनकी "असली नोड" कुंजियों के लिए खंड कुंजियों की आंतरिक रजिस्ट्री हो।

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

@thomasboyt IIRC मुख्य कार्यान्वयन बाधा mountIndex द्वारा रिएक्ट रेफरेंसिंग चाइल्ड नोड्स से आती है, यह तब काम नहीं करता है जब एक "नोड" अचानक किसी भी संख्या में नोड बन सकता है और यह माता-पिता को आमंत्रित किए बिना हो सकता है और यह भी हो सकता है कई घटक गहरे (लपेटकर)। अगर मैं गलत नहीं हूँ तो यह बहुत तुच्छ है कि रिएक्ट कई रूट तत्वों का समर्थन करता है जब तक कि संख्या कभी नहीं बदलती।

इसलिए मुझे नहीं लगता कि इसे केवल रिएक्ट में काम करना विशेष रूप से कठिन होगा, लेकिन वास्तव में उचित समाधान अधिक समस्याग्रस्त है और इसमें संभवतः mountIndex को छोड़ना शामिल होना चाहिए।

@syranide राइट; जिस समाधान पर मैं काम कर रहा हूं वह वास्तव में एक नया nodeIndex पेश करता है जिसे नोड का "असली ऑफसेट" माना जाता है (जो मुझे याद दिलाता है कि मुझे वापस जाने और mountIndex को हटाने की आवश्यकता है, क्योंकि मुझे लगता है कि यह अब मेरी शाखा में अप्रयुक्त है)।

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

मैंने फ्लेक्सबॉक्स मुद्दों में भी भाग लिया है। @syranide क्या आप कृपया अपने "getBunchOfComponents" प्रस्तावित समाधान पर थोड़ा और विस्तार कर सकते हैं? प्रतिक्रिया के लिए नया होने के नाते यह पूरी तरह से विचार करना मुश्किल है कि इस फ़ंक्शन को कहां परिभाषित किया जाए/इसे कैसे लागू किया जाए।

@landabaso

function getBunchOfComponents(...) {
  return [<ColumnA key="a" />, <ColumnB key="b" />];
}

अरे,

मैंने पूरा धागा नहीं पढ़ा है, लेकिन यहां एक रेंडर ऑप्टिमाइज़ेशन उपयोगकेस है जिसके लिए इस सुविधा की आवश्यकता हो सकती है:

http://stackoverflow.com/questions/30976722/react-performance-rendering-big-list-with-purerendermixin

यदि यह सुविधा जारी की जाती है, तो ReactCSSTransitionGroup को अब रैपर नोड की आवश्यकता नहीं होगी, है ना?

@slorber हाँ, यह शायद सच है।

प्रतिदिन इस सुविधा की आवश्यकता में भाग लें।

यदि आपके पास कई छोटे घटक हैं (यानी बहुत मॉड्यूलर रूप से डिज़ाइन करें), तो आपको सभी प्रकार की चीजों को divs में लपेटना होगा जो कि नहीं होना चाहिए। मैं भ्रमित हो सकता हूं, लेकिन मुझे लगता है कि यह इस मुद्दे से संबंधित है।

<div> के लिए आप उन्हें <div> में लपेट सकते हैं, लेकिन तालिका पंक्तियों <tr> तत्वों के लिए, यह इतना आसान नहीं है। आप <tr> को <tbody> $ में लपेट सकते हैं, लेकिन <tbody> की कई परतों को <tr> की कई परतों को लपेटना वांछनीय नहीं हो सकता है।

जिस परिदृश्य को मैंने बुलाया था, वह एक घटक रखने की कोशिश कर रहा था जो पूरी तरह से <head> रेंडरर बनने के बिना <link> और <script> तत्व प्रदान करता है।

मैंने इस मुद्दे के शीर्ष पर एक नोट जोड़ा। कृपया टिप्पणी करने से पहले इसे पढ़ें। https://github.com/facebook/react/issues/2127#issue -4166809

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

@impinball आप इन समस्याओं को हल करने के लिए प्रतिक्रिया-दस्तावेज़-शीर्षक के आधार पर प्रतिक्रिया -दस्तावेज़-शीर्षक के समान कुछ लिखने का प्रयास कर सकते हैं। मैं मेटा टैग, हेडर, शीर्षक और कभी-कभी रीडायरेक्ट के लिए ऐसा करने में सक्षम था

मैं इस समस्या का भी सामना कर रहा हूं, क्या इस समय कोई समाधान है? मुझे सुझाव के अनुसार काम करने के लिए {getBunchOfComponents()} नहीं मिला।

पहले से ही उल्लेख किए गए लोगों के अलावा कोई नहीं।

@jonchay आप एक घटक बना सकते हैं जो केवल अपने बच्चों को प्रस्तुत करता है।

function statelessWrapper(props) {
   return props.children;
}

और फिर इसका उपयोग करने के लिए:

render() {
   return (  
      <statelessWrapper>
         {renderABunchOfComponents()}
      </statelessWrapper>
    );
}

@whatknight उन मामलों को छोड़कर काम नहीं करेगा जो return renderABunchOfComponents(); पहले से काम कर रहे हैं।

  render () {
    let user = this.state.user
    let profile = user.get('data')
    let view = null

    if (user.get('status') === 'fetched') {
      view = (
        <h1>{profile.get('login')}</h1>
        <img src={profile.get('avatar_url')} />
        <dl>
          <dt>email</dt>
          <dd>{profile.get('email')}</dd>
        </dl>
      )
    } else if (user.get('status') === 'fetching') {
      view = <h1>fetching</h1>
    } else if (user.get('status') === 'error') {
      view = <h1>{profile.message}</h1>
    }

    return (
      <div className={className}>
        {view}
      </div>
    )
  }

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

@kilianc इस मामले में, आप बस लिख सकते हैं

      view = [
        <h1 key={0}>{profile.get('login')}</h1>,
        <img key={1} src={profile.get('avatar_url')} />,
        <dl key={2}>
          <dt>email</dt>
          <dd>{profile.get('email')}</dd>
        </dl>,
      ]

जिस तरह से आप इसका उपयोग कर रहे हैं, अगर यह समस्या हल हो जाती है तो इससे कोई फर्क नहीं पड़ेगा।

मुझे पहले से बताए गए कारणों के लिए इस सुविधा की आवश्यकता है, इसलिए https://github.com/mwiencek/react/tree/frag-component पर <frag></frag> कंटेनर को लागू करने का प्रयास किया

कार्यान्वयन वास्तव में सुंदर नहीं है, लेकिन अगर यह लोगों के लिए काम करता है तो मैं एक पीआर जमा कर सकता हूं और प्रतिक्रिया देवों को इसे अलग कर सकता हूं।

@mwiencek ऐसा लगता है कि आपका कार्यान्वयन काम नहीं करता है यदि एक टुकड़े में बच्चों की संख्या एक अद्यतन में बदलती है (_nestedChildCount केवल माउंटकंपोनेंट में सेट है)? यह सब ठीक से काम करने के लिए थोड़ी सी मुश्किल है। हालांकि ऐसा लगता है कि आपने अच्छी शुरुआत की है। मैं वास्तव में हाल ही में इस बारे में फिर से सोच रहा हूं और हो सकता है कि मैंने ऐसा करने का एक मजबूत तरीका निकाला हो। अगर मुझे सफलता मिलती है तो मैं वापस रिपोर्ट करूंगा।

@spicyj हाँ, तुम सही हो, मुझे उस पर गौर करना होगा ...

सुपर स्टोक्ड कि हम जल्द ही एक उचित कार्यान्वयन देख सकते हैं, हालांकि। :) अगर वे किसी भी काम के हैं तो उस शाखा से परीक्षणों की प्रतिलिपि बनाने के लिए स्वतंत्र महसूस करें।

@spicyj createFragment का उपयोग करने के लिए आगे का रास्ता नहीं है और क्या JSX उसमें बदल गया है? या क्या हम वास्तव में चाहते हैं कि टुकड़े तत्व हों?

@syranide की आखिरी टिप्पणी पर निर्माण और विस्तार करने के लिए, अतिरिक्त "फ्रैगमेंट एपीआई" की कोई आवश्यकता नहीं है यदि रेंडर रिटर्न वैल्यू के रूप में सरणी की अनुमति देता है। JSX कई रूट तत्वों को एक सरणी में बदल सकता है, जो किसी अन्य फ़ंक्शन के रिटर्न वैल्यू के लिए भी काम करेगा। इसलिए अतिरिक्त एपीआई सतह को शुरू करने के बजाय, जिसके लिए प्रलेखन और सीखने की आवश्यकता होती है, रिएक्ट की सीमाओं में से एक को हटाया जा सकता है।

यह कम से कम babel-plugin-transform-react-jsx (कार्यान्वयन) और babel-plugin-syntax-jsx (आसन्न मूल तत्वों के लिए पार्स त्रुटि को हटा रहा है) को प्रभावित करेगा। पूर्व को बदलना काफी सुरक्षित प्रतीत होता है, मुझे बाद के दायरे/उपयोग और अन्य परियोजनाओं पर प्रस्तावित परिवर्तन के प्रभाव के बारे में पता नहीं है।

वह अभी भी कई तत्वों के साथ सशर्त के उपयोग के मामले को कवर नहीं करता है। मैं एक दीर्घकालिक समाधान उचित होने के लिए "एक सरणी का उपयोग करें और मैन्युअल रूप से प्रत्येक तत्व के लिए एक मनमाना key={...} जोड़ें" पर विचार नहीं करता।

@dantman . से सहमत हूँ

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

सशर्त के लिए, इसे ट्रांसफॉर्म में भी बनाया जा सकता है या वैकल्पिक रूप से आप JSX-Control-Statements का उपयोग कर सकते हैं। इसे वहां इस तरह से लागू किया, इसलिए यह विचार आया।

अद्यतनों को सही ढंग से संभालने के लिए मुझे लगा कि @spicyj ने #5753 के लिए सोचा समाधान टुकड़ों के लिए भी काम कर सकता है (सामग्री को <!-- react-frag: 1 --><!-- /react-frag: 1 --> जैसी किसी चीज़ में लपेटना)। हाँ टिप्पणियाँ थोड़ी बदसूरत हैं, लेकिन यह जिस तरह से मैं करने की कोशिश कर रहा था उससे कहीं अधिक विश्वसनीय है _nestedChildCount । वह दृष्टिकोण अब https://github.com/mwiencek/react/tree/frag-component पर उपयोग किया जाता है

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

<GridLayout
  columns = { 3 }
>
  <FadeAnimator
    springConfig = { springConfig }
  >
    { ...cells }
  </FadeAnimator>
</GridLayout>

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

वर्तमान सीमाओं के साथ, मुझे लगता है कि आप ऐसा कुछ कर सकते हैं:

<FadeAnimator
  wrapper = {
    <GridLayout
      columns = { 3 }
    />
  }
  springConfig = { springConfig }
>
  { ...cells }
</FadeAnimator>

// FadeAnimator
render() {
  return React.cloneElement(
    props.wrapper,
    null,
    props.children
  );
}

लेकिन यह कोड को कम स्पष्ट, अधिक जटिल और लिखने में कठिन बनाता है।

रेंडर से कई घटकों को वापस करने की अनुमति देने के लिए टुकड़ा एपीआई जोड़ें！
रेंडर से कई घटकों को वापस करने की अनुमति देने के लिए टुकड़ा एपीआई जोड़ें！
रेंडर से कई घटकों को वापस करने की अनुमति देने के लिए टुकड़ा एपीआई जोड़ें！
रेंडर से कई घटकों को वापस करने की अनुमति देने के लिए टुकड़ा एपीआई जोड़ें！
रेंडर से कई घटकों को वापस करने की अनुमति देने के लिए टुकड़ा एपीआई जोड़ें！
रेंडर से कई घटकों को वापस करने की अनुमति देने के लिए टुकड़ा एपीआई जोड़ें！
रेंडर से कई घटकों को वापस करने की अनुमति देने के लिए टुकड़ा एपीआई जोड़ें！
रेंडर से कई घटकों को वापस करने की अनुमति देने के लिए टुकड़ा एपीआई जोड़ें！

@texttechne सुझाव बेहतर है। अतिरिक्त एपीआई शुरू करने के बजाय, प्रतिक्रिया को रेंडर में कई मूल तत्वों को संभालना चाहिए।

मुझे लगता है कि रेंडर में कई रूट तत्वों को संभालना मुश्किल होगा।
इसका मतलब है कि वहां: https://github.com/facebook/react/blob/master/src/renderers/shared/reconciler/ReactCompositeComponent.js#L1089

आपके पास तत्व के बजाय तत्वों की एक सरणी होगी।
इसके कारण, जहां तक ​​मैं इसे समझता हूं, अब आपको कई प्रतिक्रिया तत्वों को तुरंत चालू करना होगा: https://github.com/facebook/react/blob/master/src/renderers/shared/reconciler/ReactCompositeComponent.js# एल471

फिर, कई त्वरित प्रतिक्रिया तत्वों को माउंट करें: https://github.com/facebook/react/blob/master/src/renderers/shared/reconciler/ReactCompositeComponent.js#L471

और अच्छे क्रम में उत्पादित सभी मार्कअप का मिलान करें।

मुझे लगता है कि यह कमियों के साथ आता है जो शायद सुलह प्रक्रिया के आसपास नहीं जाना चाहते हैं।
क्या हम टुकड़ों को तत्वों के रूप में या टुकड़ों को परिवर्तनों के आसपास चीनी वाक्यविन्यास के रूप में रखना चाहते हैं?

मुझे लगता है कि एक तत्व के रूप में टुकड़ा ठीक है, हमें टेक्स्ट नोड्स या खाली नोड्स के समान एक नया प्रकार का आंतरिक नोड बनाना होगा, है ना? हालांकि मुझे नहीं पता कि हम उन्हें कैसे मैनेज करेंगे।

उदाहरण के लिए, जब जड़ों में से कोई एक अनमाउंट होता है तो आप कैसे संभालते हैं? आप अपडेट को ठीक से कैसे संभालते हैं?
या, आप DevTools के अंदर कई जड़ों को कैसे प्रबंधित करते हैं? (स्पष्ट उत्तर: DevTools को ठीक करें...)

मुझे लगता है कि एक टुकड़ा एक समग्र घटक है। वास्तव में अंतर कहाँ है?
यदि हम टुकड़ों को लागू करने के लिए डुप्लिकेट कोड को समाप्त करते हैं, तो हम रिएक्ट आंतरिक "प्राचीन" रखने के लिए चीनी सिंटैक्स को बेहतर ढंग से लागू करेंगे?

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

<p>Hi</p>
<p>There</p>

परिणाम दो "एक नए रूट में प्रस्तुत करें" कॉल में होंगे।

एक कॉल के बजाय अगर हम एक रैपर का इस्तेमाल करते हैं, है ना? प्रदर्शन के बारे में क्या? सादगी? सच कहूं तो, मेरी भावना है: हमें इस स्थिति को संभालने के लिए रिएक्ट इंटर्नल को नहीं छूना चाहिए। बल्कि, क्या हम JSX के साथ इस उपलब्धि को हासिल कर सकते हैं? क्या हम JSX सिंटैक्स में सुधार कर सकते हैं?

(_अस्वीकरण_: मैं पूरी तरह से आंतरिक प्रतिक्रिया करने के लिए अभ्यस्त नहीं हूं, और कुछ हिस्से हो सकते हैं जिन्हें मैं पूरी तरह से समझ नहीं पाया या जो मुझे समझ में नहीं आया। गलतफहमी के लिए मैं क्षमा चाहता हूं।)

संपादित करें: चीजों को ठीक करना/स्पष्ट करना। साथ ही, गिटहब रहस्यमय तरीके से ईमेल को अजीब तरह से स्टाइल करता है, इसलिए मुझे कोड ब्लॉक को दोबारा सुधारना पड़ा ... :-(

नमस्ते, कोर मिथ्रिल योगदानकर्ता / कमिटर यहाँ।

टीएल; डीआर: एपीआई और इंटर्नल होने पर भी टुकड़े बेहद कठिन होते हैं
सरल।

वैसे, मैं अनुभव से जानता हूं कि इसे लागू करना बहुत मुश्किल है। इस
मिथ्रिल के लिए भी कई बार अनुरोध किया गया है, लेकिन इस वजह से मना कर दिया गया है
सरासर कठिनाई। इसे लागू करने का हर प्रयास विफल रहा है at
परीक्षण सूट का कम से कम एक तिहाई विफल हो रहा है।

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

यहाँ टुकड़ों के साथ पकड़ है: आपको उन्हें पूरी तरह से प्रबंधित करना होगा
आंतरिक रूप से या आप उन्हें ठीक से अलग नहीं करते हैं। यहां तक ​​की
document.createContextualFragment बेकार है। एक उदाहरण के रूप में, आइए
दो पेड़ों को बदलना, छोड़े गए प्रतिपादन:

// Before
A {}
fragment {
  B[class="foo"] {}
  B[class="bar"] {}
}
C {}
D {}

// After
A {}
B[class="foo"] {}
fragment {
  C {}
}
D {}

इसके लिए सही परिवर्तन B तत्वों और C $ तत्वों को बदलना चाहिए, बाकी को अछूता छोड़ देना चाहिए। यह पता लगाना गैर-तुच्छ है, और आपको मूल रूप से टुकड़े के बच्चों को इस तथ्य की अनदेखी करते हुए पुनरावृति करना होगा कि वे एक टुकड़े में हैं।

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

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

शब्दों के लिए सभी का धन्यवाद। हम जानते हैं कि यह कठिन है और अभी भी यह हमारी टू-डू सूची में है। (उत्साह से पूछने से यह जल्दी नहीं होगा @janryWang।)

@isiahmeadows FYI करें, मिथ्रिल की पुनर्लेखन शाखा अंशों का समर्थन करती है।

@spicyj कार्यान्वयन पर एक नज़र डालने के लिए आपका स्वागत है [1] [2] और परीक्षण [1] [2] यदि आप पहले से इसका पालन नहीं कर रहे हैं। संपूर्ण अंतर इंजन केवल 400 LOC के बारे में है, इसलिए उम्मीद है कि इसका पालन करना आसान होना चाहिए

@isiahmeadows मुझे लगता है कि GitHub ने आपकी टिप्पणी का हिस्सा खा लिया। कोड ब्लॉक टूटा हुआ है, और मैं <D /> का पहला उदाहरण पारित नहीं देख सकता।

हालांकि ई-मेल में ठीक लग रहा है। शायद आपको गिटहब में एक बग मिला?

दुर्भाग्य से गिटहब की मार्कडाउन हैंडलिंग एक ईमेल से एक टिप्पणी आने पर अलग तरह से व्यवहार करती है। मैंने एक रिक्त रेखा को हटाने के लिए टिप्पणी संपादित की और अब यह दिखाई देती है।

मैंने मूल ई-मेल को support@github पर अग्रेषित कर दिया। उम्मीद है, वे पार्सर को ठीक कर सकते हैं। मैं

@lhorie आप टुकड़े के लिए सरणी वाक्यविन्यास का उपयोग करते हैं?
क्या आपके पास DocumentFragment के लिए पॉलीफ़िल है?

और एक "छद्म" रैपर तत्व का उपयोग करना, जैसे HTML टिप्पणी एक विकल्प नहीं है? मैंने सोचा था कि जिस तरह से टेक्स्ट नोड्स "हल" थे ...

उस टिप्पणी को ठीक करने के लिए धन्यवाद @spicyj

चिंताओं को दूर करने के लिए @isiahmeadows ने अपने उदाहरण में लाया: नया मिथ्रिल इंजन _not_ उस शब्दार्थ का पालन करता है जिसे @isiahmeadows ने कई कारणों से सुझाया है:

• उन शब्दार्थों को लागू करने से _महत्वपूर्ण_ अधिक जटिल हो जाएगा
• यह चाबियों और कुंजी से संबंधित बगों के बारे में तर्क करना मुश्किल बना देगा क्योंकि महत्वपूर्ण रिक्त स्थान घटकों से और यहां तक ​​​​कि भाई और उपचाइल्ड घटकों में भी खून बहना संभव हो जाता है।
• यह खंड जीवनचक्र को गैर-सहज बना देगा (उदाहरण के लिए, उस उदाहरण में, B.bar हटा दिया गया है, लेकिन ऐसा ही टुकड़ा है, और सी को लपेटने के लिए एक नया टुकड़ा बनाया गया है)। यह सामान्य सिद्धांत का उल्लंघन करता है कि जीवनचक्र "कैस्केड" है, जिसका अर्थ है कि अब आप यह सुनिश्चित नहीं कर सकते हैं कि यदि किसी दिए गए पैरेंट नोड को हटा दिया जाता है तो एक चाइल्ड नोड को हटा दिया जाता है। पिछले बिंदु की तरह, इसमें एक घटक की इनकैप्सुलेशन क्षमताओं पर रिसाव होने की संभावना है।
• यदि, काल्पनिक रूप से, कोई एक भिन्न इंजन से संबंधित अलग-अलग मुद्दों में भाग लेता है जो उन शब्दार्थों का पालन नहीं करते हैं, तो एप्लिकेशन-स्पेस समाधान उतना ही तुच्छ है जितना कि आपत्तिजनक नोड के चारों ओर एक टुकड़ा लपेटना।

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

ध्यान दें कि मैंने अपनी टिप्पणी तय की है। मैंने कुछ गलतियाँ की हैं, और गिटहब ईमेल प्रतिक्रियाओं को अच्छी तरह से स्टाइल नहीं करता है ... :frowning:

@Primajin मैंने यह भी सोचा है, लेकिन मुझे संदेह है कि उन्हें एक तत्व के रूप में पारित किया जाएगा। टुकड़ों को रचना योग्य बनाना महत्वपूर्ण है ( ऊपर मेरा उदाहरण देखें)। हालाँकि, कई बार आप उन्हें एक इकाई के रूप में भी देखना चाहेंगे।

शायद, React.Children.map को टुकड़ों का विस्तार करना चाहिए। यदि आप प्रत्येक बच्चे (बाल टुकड़ों के बच्चों सहित) पर पुनरावृति करना चाहते हैं, तो Children.map का उपयोग करें। यदि आप टुकड़ों को एक अपारदर्शी बॉक्स के रूप में देखना चाहते हैं, तो सीधे प्रॉप्स के साथ काम करें। बच्चों को एक {सरणी, तत्व} के रूप में।

@lhorie मैं फिर से लिखने में शामिल नहीं हूं, हालांकि, मैं इसकी जटिलताओं से परिचित नहीं हूं। मैं इस तथ्य में व्यस्त हूं कि मेरे पास इस सप्ताह एक फाइनल है और अगले सप्ताह तीन है, साथ ही मैं किसी ऐसे व्यक्ति के साथ काम कर रहा हूं जो मेरे कॉलेज को इंटर्नशिप की आवश्यकता है। मेरा ध्यान Techtonic को खत्म करने पर भी रहा है, जिसे मैंने _लगभग_ CLI कर लिया है (एक परीक्षण टूट गया है जो नहीं होना चाहिए)।

@isiahmeadows विषय पर बने रहने के लिए बस एक दोस्ताना अनुस्मारक। यदि आप अन्य विषयों के बारे में बात करना चाहते हैं तो बेझिझक मिथ्रिल गटर रूम का उपयोग करें।

@appsforartists

शायद, React.Children.map को टुकड़ों का विस्तार करना चाहिए

मिथ्रिल स्थिर आंतरिक रूप से कुछ ऐसा ही करता है (यानी उप-सरणियों को समतल करना), लेकिन मैं उस मॉडल से पूर्ण कारणों से दूर जा रहा हूं (और कुछ ऐतिहासिक सिरदर्द के कारण vnode सूचियों के बारे में जो मिश्रित कुंजी और गैर-कुंजी वाले नोड्स हैं)। विचार करने योग्य बात हो सकती है।

और एक "छद्म" रैपर तत्व का उपयोग करना, जैसे HTML टिप्पणी एक विकल्प नहीं है? मैंने सोचा था कि जिस तरह से टेक्स्ट नोड्स "हल" थे ...

हम कुछ महीनों से उत्पादन में https://github.com/mwiencek/react-packages का उपयोग कर रहे हैं। यह इस टिप्पणी आवरण दृष्टिकोण का उपयोग करता है, इसलिए टुकड़ों को स्पष्ट रूप से नेस्टेड किया जा सकता है।

@mwiencek कस्टम प्रतिक्रिया पैकेज के बिना आपके दृष्टिकोण का उपयोग करना संभव है?

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

तो अगर आप क्रम में vdom पेड़ का पालन करते हैं, तो आपको टिप्पणियों की आवश्यकता नहीं है, या आप करते हैं?

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

सख्ती से नहीं, लेकिन उन्होंने इस उदाहरण में कार्यान्वयन को सरल बना दिया।

तो अनिवार्य रूप से प्रतिक्रिया के साथ उचित विवरण सूची <dl> बनाना संभव नहीं है?

<dl>
  <dt>Def 1</dt>
  <dd>Some description</dd>
  <dt>Def 2</dt>
  <dd>Some other description</dd>
</dl>

@KaiStapel यह मुद्दा render() से कई घटकों (या मुझे लगता है कि तत्वों) को वापस करने के बारे में है। जब तक आपका render फ़ंक्शन केवल एक मूल तत्व/घटक देता है, इसे काम करना चाहिए।

ठीक:

render() {
  return (
    <dl>
      <dt>Def 1</dt>
      <dd>Some description</dd>
      <dt>Def 2</dt>
      <dd>Some other description</dd>
    </dl>
  )
}

ठीक नहीं है:

render() {
  return (
    <h2>my list</h2>
    <dl>
      <dt>Def 1</dt>
      <dd>Some description</dd>
      <dt>Def 2</dt>
      <dd>Some other description</dd>
    </dl>
  )
}

@GGAlanSmithee अच्छी तरह से हाँ हार्डकोड किया गया है, लेकिन आप ऐसा नहीं कर सकते:

<dl>
   loop here and print out dt/dd pairs
</dl>

जो बहुत दुखद है। वही पंक्तियों के साथ तालिकाओं के लिए भी जाता है, क्योंकि आप एक बार में दो <tr> तत्वों को प्रस्तुत नहीं कर सकते हैं :(

ऊपर से:

"मैं भी" और "+1" मूल्यवान नहीं हैं, न ही ऐसे उपयोग के मामले हैं जो पहले ही टिप्पणियों में लिखे जा चुके हैं (उदाहरण के लिए, हम जानते हैं कि आप <tr> या <dd> तत्वों को <div> के साथ नहीं डाल सकते हैं) .

यह देखते हुए कि https://github.com/mwiencek/react-packages में एक कामकाजी समाधान है, क्या कोई मौका है कि यह जल्द ही प्रतिक्रिया का हिस्सा होगा? या हम नए सुलहकर्ता की प्रतीक्षा कर रहे हैं?

यह देखते हुए कि https://github.com/mwiencek/react-packages में एक कार्यशील समाधान है

क्या आप इसे वास्तविक परियोजनाओं में सफलतापूर्वक उपयोग कर रहे हैं?

@mwiencek

कार्यान्वयन वास्तव में सुंदर नहीं है, लेकिन अगर यह लोगों के लिए काम करता है तो मैं एक पीआर जमा कर सकता हूं और प्रतिक्रिया देवों को इसे अलग कर सकता हूं।

ज़रूर, कृपया एक जनसंपर्क भेजें!

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

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

@gaearon क्या मैं केवल यह बता सकता हूं कि सहायक टुकड़े बहुत सरल हैं, यह सिर्फ चीनी है, मैं वर्तमान में एक छोटे से छोटे आवरण के माध्यम से <frag> का उपयोग कर रहा हूं। क्या कई बच्चों को घटक रूट के रूप में वापस करना वास्तव में महत्वपूर्ण है?

@syranide मैं बीटा वातावरण में फ्रैग के साथ कस्टम बिल्ड का उपयोग कर रहा हूं, हालांकि मैं इसके बजाय आधिकारिक रिएक्ट बिल्ड का उपयोग करना चाहूंगा। क्या आप अपना <frag> रैपर प्रदान कर सकते हैं? :) धन्यवाद

@amertak

import React from 'react';
import createFragment from 'react-addons-create-fragment';

let nativeCreateElement = React.createElement;

React.createElement = function() {
  if (arguments[0] !== 'frag') {
    return nativeCreateElement.apply(this, arguments);
  }

  let length = arguments.length;
  if (length <= 2) {
    return null;
  }

  let children = {};
  for (let i = 2; i < length; i++) {
    children['~' + (i - 2)] = arguments[i];
  }

  return createFragment(children);
};

पिछली टीम मीटिंग में हमने इस बारे में और बात की थी। आम सहमति यह है कि हम इस विशेष कार्यान्वयन के साथ नहीं जाना चाहते हैं। हालांकि इस फीचर को लॉन्ग टर्म कोर रीराइट में सपोर्ट किया जाएगा (अभी इस पर कोई टाइमलाइन नहीं है)।

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

हम किस पर काम करते हैं, इसका एक बेहतर विचार प्राप्त करने के लिए, कृपया हमारे मीटिंग नोट्स रेपो देखें! आप इस पर हमारी नवीनतम चर्चा https://github.com/reactjs/core-notes/blob/master/2016-07/july-07.md पर देख सकते हैं।

@gaearon कम से कम आधिकारिक फ्रैग-वाक्यविन्यास होने पर कर्षण के साथ दिलचस्प होगा।

@syranide कोड के लिए धन्यवाद, लेकिन दुर्भाग्य से ऐसा लगता है कि मैं इसका उपयोग नहीं कर सकता क्योंकि मुझे रूट ऐप घटक के रूप में frag की आवश्यकता है जिसे ReactDOM.render विधि द्वारा रेंडरर किया जा रहा है और यह विधि खंड को स्वीकार नहीं करेगी .

वैसे भी धन्यवाद, यह अन्य लोगों के लिए उपयोगी होगा जिन्हें ऐप रूट के रूप में frag की आवश्यकता नहीं है।

@amertak हाँ यह केवल टुकड़े बनाने के लिए एक अधिक उचित वाक्यविन्यास को सक्षम करने के लिए है, यह कोई नई सुविधा नहीं जोड़ता है।

@syranide
मैं सोच रहा था कि क्या मैन्युअल रूप से टिप्पणी प्रस्तुत करना संभव होगा और इलाज एक अन्य घटक के रूप में है (जो आवश्यक नहीं हो सकता है)?
आंतरिक रूप से टिप्पणियों को #comment प्रकार के रूप में नियंत्रित किया जाता है ताकि शायद कॉल करने में सक्षम हो
React.createComponent('#comment', { ... }, children) ?
एक विचार है। छोटा उपाय।

यहाँ जो मुख्य चीज़ गायब है वह है comment नोड को रेंडर करने में सक्षम होना, क्या मैं सही हूँ? :)

@gaearon थोड़ा दुखी है कि यह जल्द नहीं आ रहा है, लेकिन मैं पारदर्शिता की सराहना करता हूं। अच्छा लिखो!

एक अद्यतन तक एक वैकल्पिक समाधान?
मेरे लिए, मुझे Botstraap . का एक ड्रॉपडाउनमेनू प्रस्तुत करना होगा

render(){
    return (
        <ButtonNotification/>
        <ul className="dropdown-menu">
            {this.state.items.map(this.addItem)}
        </ul>
    );
}

ReactDOM.render(
    React.createElement(NotificationHandler, null),
    document.getElementById("listNotification")
);

लेकिन संभव नहीं है, एक विचार?
धन्यवाद,

http://getbootstrap.com/components/#btn -dropdowns-single

यह स्पष्ट रूप से एक <div class="btn-group"> में लपेटा गया है जैसा कि डॉक्स में दिखाया गया है

हां बिल्कुल, लेकिन <div class="btn-group"> में लिपटे दो तत्व हैं।

render(){
    return (
        <ButtonNotification/> //ELEMENT 1
        <ul className="dropdown-menu"> //ELEMENT 2
            {this.state.items.map(this.addItem)}
        </ul>
    );
}

ReactDOM.render(
    React.createElement(NotificationHandler, null),
    document.getElementById("listNotification") //is DIV#listNotification
);

<div id="listNotification" class="btn-group"><!--wrap-->
    <a href="#">button notification</a> <!--ELEMENT1-->
    <ul> <!--ELEMENT2-->
        <li></li>
        <li></li>
    </ul>
</div>

और एक तत्व में लिपटे दो तत्व संभव नहीं है,
आपके समय के लिए धन्यवाद @Primajin

बस सब कुछ एक स्तर पर शिफ्ट करें:

render(){
    return (
        <div className="btn-group"> //WRAP
            <ButtonNotification/> //ELEMENT 1
            <ul className="dropdown-menu"> //ELEMENT 2
                {this.state.items.map(this.addItem)}
            </ul>
        </div>
    );
}

ReactDOM.render(
    React.createElement(NotificationHandler, null),
    document.getElementById("listWrapper") //or whatever your list is called
);

ठीक है, लेकिन मेरे पास माता-पिता में अन्य आइटम हैं।
यह केवल समस्या को दूर करेगा।

<div ...> <--!listWrapper-->
    <div class="btn-group">....</>
    <div class="btn-group">....</>
    <--!React-->
    <div class="btn-group"> //WRAP
        <ButtonNotification/> //ELEMENT 1
        <ul className="dropdown-menu"> //ELEMENT 2
            {this.state.items.map(this.addItem)}
        </ul>
    </div>
    <--!React-->
    <div class="btn-group">....</>
</div>

और इस मामले में, रिएक्ट सभी निहित को बदल देगा।
क्या अन्य तत्वों को बदले बिना "ऐड" करना संभव है?

धन्यवाद,

@ rifton007 ऐसा नहीं है कि यह कैसे काम करता है। आपके पास एक कंटेनर में लिपटे भाई-बहन के रूप में कई तत्व/घटक हो सकते हैं। प्रतिबंध यह है कि एक घटक return एकाधिक तत्व नहीं कर सकता है। आपके द्वारा अभी पोस्ट किया गया कोड काम करेगा।

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

क्षमा करें, मैं सिर्फ यह जानना चाहता था कि इस बीच किसी के पास वैकल्पिक समाधान होगा या नहीं।
यदि आवश्यक हो तो आप मेरी पोस्ट हटा सकते हैं।

मैं फ्रेमवर्क 7 और रिएक्ट के साथ ऐप बनाता हूं, हालांकि फ्रेमवर्क 7 एचटीएमएल प्रारूप तय है,

<div class="page"><div class="navbar"></div><div class="searchbar"></div><div class="page-content"></div><div class="toolbar"></div></div>

मैं प्रथम स्तर के बाल तत्वों (नेवबार, सर्चबार) को अन्य div में लपेट नहीं सकता, जिसमें 'पृष्ठ' वर्ग नहीं है

मेरे पास एक घटक है जो पंक्तियों की एक सूची देता है

FYI करें, जिस पुनर्लेखन पर हम काम कर रहे हैं (#6170) पहले से ही अंशों का समर्थन करता है। आप हमारी प्रगति को #7925 और http://isfiberreadyyet.com पर ट्रैक कर सकते हैं।

केवल तथ्य यह है कि <table> तत्व कुछ तत्वों को प्रस्तुत नहीं कर सकता है, वेब एपीआई के साथ संगत होने के लिए इस सुविधा को जोड़ने के लिए पर्याप्त कारण है।

संपादित करें: आह, टुकड़े! उनके लिए तत्पर हैं।

@trusktr

जैसा कि इस सूत्र में पहली पोस्ट में बताया गया है:

अनुरक्षकों से नोट:

हम जानते हैं कि यह एक समस्या है और हम जानते हैं कि वास्तव में किस समस्या का समाधान किया जा सकता है । हम भी यही चाहते हैं लेकिन यह हमारे मौजूदा आर्किटेक्चर के साथ एक कठिन समस्या है। इस सुविधा की इच्छा व्यक्त करने वाली अतिरिक्त टिप्पणियां सहायक नहीं हैं।

मैं

गोश डांग, मुझे ऐसा करना बंद करना होगा।

मैंने इसे ऊपर उठाया लेकिन एक वैध उपयोग केस साझा करना चाहता था। मान लीजिए मेरे पास 3 बटन हैं जो मुझे एक सीएसएस तरल लेआउट (बाएं, केंद्र, दाएं) चाहिए। बायां बटन हमेशा दिखाई देता है, लेकिन अन्य दो सशर्त रूप से दृश्यमान होते हैं। रिएक्ट (विशेष रूप से रिएक्ट नेटिव) में, मैं इसके फ्लेक्सबॉक्स का उपयोग कर रहा हूं और इसे इस प्रकार प्रस्तुत कर रहा हूं:

[ Left ] { renderCenterAndRightButtons(this.state.someFlag) }

मध्य और दाएँ बटन सही ढंग से स्थिति में नहीं हैं क्योंकि वे एकवचन दृश्य में लिपटे हुए हैं।

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

[ Left ] { renderCenterButton(this.state.someFlag) } { renderRightButton(this.state.someFlag) }

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

मुझे लगता है कि हम इसे बंद कर सकते हैं।

रिएक्ट 16 बीटा 1 के बाद से घटकों से वापसी सरणियों का समर्थन किया जाता है जिसे आप अभी आज़मा सकते हैं ।

अभी भी कुछ सीमाएँ हैं (SSR समर्थन तैयार नहीं है) लेकिन हम उन्हें #8854 में ट्रैक कर रहे हैं और अंतिम 16 रिलीज़ से पहले ठीक कर देंगे।

आपकी प्रतिक्रिया के लिए सभी को धन्यवाद!

धन्यवाद दानी

मैं

मैं

@gaearon बहुत बढ़िया सुधार! क्या यह शुद्ध टेक्स्ट नोड का समर्थन करता है?

हां, यह लौटने वाले तारों का भी समर्थन करता है।

क्या मैं पूछ सकता हूं कि यह कैसे काम करना चाहिए?

मैं उम्मीद कर रहा था कि यह हमें 2 आसन्न XJS तत्वों को प्रस्तुत करने की अनुमति देगा, लेकिन अगर मैं return ["foo", "bar"] (कुछ और उपयोगी;) करता हूं, तो मुझे अपेक्षित bundle.js:66656 Warning: Each child in an array or iterator should have a unique "key" prop. मिलता है

तो क्या यह सुविधा एक बाहरी तत्व द्वारा वास्तविक सूची को घेरने का एक तरीका नहीं था?

तो क्या यह सुविधा एक बाहरी तत्व द्वारा वास्तविक सूची को घेरने का एक तरीका नहीं था?

हां, एक रेंडर से कई तत्व प्रदान करने का एक तरीका। (अधिक जानकारी के लिए, प्रारंभिक अंक पोस्ट देखें।)

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

@diligiant की वापसी ['foo', 'bar'] इस मुद्दे के लिए प्रासंगिक नहीं है। आप return <div>{['foo','bar']}</div> कभी नहीं कर सकते हैं और अभी भी नहीं कर सकते हैं एक सरणी में प्रत्येक बच्चे के पास 'कुंजी' प्रोप होना चाहिए चाहे वह <div> जैसे आंतरिक जेएसएक्स टैग में हो या इसे वापस किया जा रहा हो। अब आप क्या कर सकते हैं:

return [<div key='1'>foo</div>, <span key='2'>bar</span>];

यह प्रतिक्रिया में एक बड़ी सीमा को हटा देता है।

बीटीडब्ल्यू ['foo', 'bar'] लौटाने से आपको कोई त्रुटि नहीं एक चेतावनी मिलती है और उस चेतावनी को हटाने के लिए आप आसानी से उन तारों में शामिल हो सकते हैं या यदि वे जेएसएक्स टैग हैं और स्ट्रिंग नहीं हैं तो आप उनमें एक महत्वपूर्ण प्रोप जोड़ सकते हैं। तो सरणी लौटने के बारे में कोई सीमा नहीं है।

@JesperTreetop धन्यवाद।
@sassanh , आपके उदाहरण से, ऐसा लगता है कि मैं आसपास के (अर्थात्) बेकार <div> से बचने के लिए "बस" कुंजियों का उपयोग करने के लिए "शर्मीली" हूं। क्या आपका मतलब है कि मुझे आगे बढ़ना चाहिए और कोई वास्तविक प्रदर्शन दंड नहीं है? यह वास्तव में एक वास्तविक सुधार होगा!

@diligiant मुझे संदेह है कि यह किसी भी प्रदर्शन दंड का परिचय देता है लेकिन आपको आसपास के बेकार div की आवश्यकता नहीं है जब तक कि यह आसपास के तार न हो और यदि यह आसपास के तार हैं तो आप सरणी से बच सकते हैं और तारों में शामिल हो सकते हैं। यदि यह तार नहीं है तो आप घटक में कुंजी जोड़ सकते हैं। उदाहरण के लिए यदि आपके पास दो घटक Foo और Bar हैं तो आप [<Foo key='foo'/>, <Bar key='bar'/>] वापस कर सकते हैं और आपको न तो अपने घटकों (हमेशा की तरह) को घेरने की आवश्यकता नहीं है और न ही आपकी सरणी (धन्यवाद के लिए) यह नई रिलीज, आपको 16 से पहले सरणी को घेरने की जरूरत है)।

@sassanh तब शांत। बेशक मेरा उपयोग मामला कई घटकों के साथ था। प्रसन्न!! ;)

असल में यह मेरे लिए अजीब लगता है कि जब सभी आइटम स्ट्रिंग होते हैं तो हम लापता चाबियों के बारे में चेतावनी देते हैं। मुझे उम्मीद नहीं थी कि हम ऐसा करेंगे। क्या यह मौजूदा व्यवहार 15 में है जब तार एक div के अंदर होते हैं? यदि नहीं, तो हमें इसे शीर्ष-स्तरीय स्ट्रिंग्स के लिए 16 में ठीक करना चाहिए (क्योंकि उन्हें कुंजी देना असंभव है)।

@gaearon क्षमा करें, मेरा उदाहरण भ्रामक था: मेरा मतलब था घटक।

मैंने जाँच की और -beta.5 के तहत, कई स्ट्रिंग्स के साथ एक सरणी प्रस्तुत करते समय प्रतिक्रिया एक चेतावनी जारी नहीं करता है।

फिर भी, मैं key आवश्यकता से हैरान हूं जब एक सरणी को केवल आसपास के घटक से बचने के लिए प्रस्तुत किया जाता है। मैं समझता हूं और यह कुछ भी नहीं है, लेकिन शायद यह SO पर बहुत सारे प्रश्न उठाएगा (हालांकि मेरे पास पेशकश करने के लिए कुछ भी बेहतर नहीं है ...)

और अंत में, फिर से धन्यवाद।

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

.. और अधिकांश समय मैं किसी फ़ंक्शन से एक सरणी लौटा रहा हूं , मुझे key चेतावनी जगह चाहिए। ऐसा लगता है कि आप नहीं चाहेंगे कि चेतावनी अल्पमत है, और प्रतिक्रिया के लिए यह जानने का कोई तरीका नहीं है कि चेतावनी देना उचित है या नहीं।

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

सीधे रेंडर से लौटाए गए सरणियों और एक डिव के अंदर सरणियों के बीच कोई वैचारिक अंतर नहीं है। तो कोई कारण नहीं है कि एक मामले में महत्वपूर्ण चेतावनी क्यों होगी लेकिन दूसरे में नहीं। उन्हें उसी तरह काम करने की ज़रूरत है क्योंकि चाबियां गुम होने पर दोनों एक ही समस्या से प्रभावित होते हैं।

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

भविष्य में हम सिंटैक्स के साथ JSX में टुकड़ों के लिए स्पष्ट समर्थन जोड़कर इसे हल कर सकते हैं:

return (
  <>
    <div>child 1</div>
    <div>child 2</div>
  </>
);

यह एक सरणी उत्पन्न कर सकता है लेकिन बच्चों को संख्यात्मक अनुक्रमणिका प्रदान कर सकता है क्योंकि इस मामले में हम जानते हैं कि वे कभी भी पुन: व्यवस्थित नहीं कर सकते हैं। JSX चाइल्ड एक्सप्रेशन द्वारा दी गई यह गारंटी ठीक वही है जो हमें सामान्य JSX कोड में कुंजियों को निर्दिष्ट किए बिना दूर जाने देती है जहाँ एक div में कई बच्चे हो सकते हैं।

लेकिन हमारे पास अभी तक यह सिंटैक्स नहीं है। तो अभी के लिए यह एक ज्ञात सीमा है।

@JesperTreetop और @zwily , @gaearon ने इसे मेरे द्वारा किए गए तरीके से बेहतर तरीके से समझाया;)

एक बार जब आप जानते हैं, तो यह कोई बड़ी बात नहीं है, लेकिन जैसा कि हम सभी चाहते हैं कि रिएक्ट फले-फूले, मैं बस इतना कह रहा था ...

@gaearon क्या <> सिंटैक्स प्रस्ताव के लिए कोई और मुद्दा है जिसे हम इस मुद्दे पर आगे की चर्चा के बजाय देख सकते हैं? मैंने इधर-उधर खोजा लेकिन मुझे कोई नहीं मिला।

@smrq +1 प्रश्न करने के लिए - मैं उन अजीब सीमाओं के बारे में सब कुछ का पालन करता हूं (एक-से-एक rendrer() परिणाम, कुंजियाँ और JSX सिंटैक्स या टुकड़े) लेकिन मुझे पता है कि एकमात्र टिकट https://github.com/ है

मुझे यह भी लगता है कि फाइबर चाबियों के साथ समस्या को ठीक कर देंगे - लेकिन ऐसा लगता है कि यह अधूरा सपना है

कुंजियाँ एक "मुद्दा" नहीं हैं। :) वे किसी भी दृश्य ढांचे का एक मौलिक और आवश्यक हिस्सा हैं जो आपको गतिशील सूचियां बनाने की अनुमति देता है।

अधिक विस्तृत विवरण के लिए https://facebook.github.io/react/tutorial/tutorial.html#keys देखें।

@spicyj वास्तव में यह एक «मुद्दा» है क्योंकि यह डेवलपर्स से विस्तारित ऊर्जा खर्च का कारण बनता है और ऐसी आवश्यकता के बिना प्रोग्राम व्यू फ्रेमवर्क की मौलिक संभावना है (उदाहरण के लिए https://github.com/dfilatov/vidom)

ऐसी आवश्यकता के बिना प्रोग्राम व्यू फ्रेमवर्क की मौलिक संभावना है (उदाहरण के लिए https://github.com/dfilatov/vidom)

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

@ गोटो-बस-स्टॉप vidom चाबियों का उपयोग कर सकता है, लेकिन उनकी आवश्यकता नहीं है और उनके बिना केवल बहुत सारे अपडेट वाले बड़े मामले ही वास्तविक प्रदर्शन समस्याओं का कारण बन सकते हैं

इसलिए मैं इस भाग को संभव वैकल्पिक मानता हूं (उदाहरण के लिए, shouldComponentUpdate ) जिसका उपयोग अलग-अलग मामलों में फेरफॉर्मेंस ट्वीक के लिए किया जा सकता है

बिना चाबियों के संघर्ष करने वाले vidom का @veged उदाहरण ।

यह पता नहीं है कि यह तत्वों को पुन: व्यवस्थित करने वाला है, इसलिए यह मूल घटक के प्रत्येक रेंडर पर उदाहरणों को त्याग देता है।

किसी ऐसे व्यक्ति के रूप में जो वर्चुअल-डोम स्पेस से काफी परिचित है [1]। मैं कह सकता हूँ:

1. समान भाई-बहनों के बीच प्रेडिक्टेबल डोम और स्टेट अपडेट के लिए कुंजियाँ आवश्यक हैं।
2. कुंजियाँ आमतौर पर एक अनुकूलन नहीं होती हैं, और - वास्तव में - आमतौर पर विपरीत होती हैं।

[1] https://github.com/leeoniya/domvm

हालाँकि, यहाँ स्पष्ट मुद्दा (जैसा कि @gaearon वर्णित है) सरणियों का पूरी तरह से स्थिर उपयोग है और स्थिर सरणियों और स्थिर JSX अंशों के बीच का अंतर है

@ब्रिगैंड ओ में कोई संदेह नहीं है कि राज्य-पूर्ण घटकों के पुन: व्यवस्थित करने से कुछ समस्याएं हो सकती हैं ;-) लेकिन इसके लिए संघर्ष करने के लिए हर दूसरे मामलों (मेरी राय में उनमें से अधिक) को मजबूर करें ... विवादास्पद दिखता है

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

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

मैं पूरी तरह से सहमत हूं कि जब सूची स्थिर होती है और कभी भी पुन: व्यवस्थित नहीं होती है तो कुंजी निर्दिष्ट करना असुविधाजनक होता है। JSX रेपो पर इस पर चर्चा करने के लिए आपका स्वागत है। अगर आपको इसके लिए कोई समस्या नहीं मिलती है, तो वहां एक नया मुद्दा बनाने के लिए आपका स्वागत है।

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

@smrq ने jsx रेपो पर <> सिंटैक्स के लिए एक प्रस्ताव मुद्दा बनाया: https://github.com/facebook/jsx/issues/84।

हमने अभी एक नए React.Fragment निर्यात और संबद्ध <> सिंटैक्स के लिए समर्थन जारी किया है:
https://reactjs.org/blog/2017/11/28/react-v16.2.0-fragment-support.html