لأنه عندما لا تضع الغلاف ، فإنه يتلاشى إلى هذا:

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

التي لا تجعل المعنى النحوي. قد تساعدك صفحة برنامج التحويل البرمجي jsx إذا كنت بحاجة إلى تعيين مرئي.

ومع ذلك ، من الممكن إلغاء هذا إلى [div, div] بدلاً من ذلك. هذا صعب ومثير للجدل إلى حد ما ولن يتم تنفيذه في المستقبل القريب.

(لا أعتقد أنه مثير للجدل بشكل خاص ولكنه يضيف تعقيدًا للشفرة ولم يتم تنفيذه بعد.)

لدى IIRCsyranide بعض التعليقات حول هذا الموضوع

تضمين التغريدة

لقد أجريت محادثة قصيرة حول هذا الموضوع مع 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"> في هذه الحالة. (إذا فهمت هذا بشكل صحيح)

إنه يؤثر أيضًا على محددات css بنفس الطريقة التي نشرها 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. حسنًا ، قصدت إشعارًا في وثائق React. نعم ، لقد أظهرت وحدة التحكم خطأً ، لكن الحاجة إلى الالتفاف لم تكن منطقية بالنسبة لي في البداية. هذا هو السبب في أنني بحثت ووصلت إلى هنا.

لقد شعرت بهذا الألم أيضًا ... مؤلم بشكل خاص لمصممي ، في واقع الأمر. سيكون من الجيد نوعًا ما إذا كان المكون يمكنه إخراج عقدة (وبالتالي قائمة العقدة أو جزء) بدلاً من عنصر.

أقول فقط .. أنا لا أدعو إلى إعادة أطفال متعددين من المكون _ ولكن_ أود أن أفعل ذلك بأساليب 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()} /> لتجنبه ( تحرير: على الرغم من أنه من الواضح أنه لا يمكنك استخدام ذلك إذا كان لديك أطفال مجاورون ، فيمكنك استخدام بعض أدوات المساعدة المسطحة ... لكن نعم).

حالة أخرى واجهت مجموعة أدوات واجهة المستخدم. عندما تضع الأطفال داخل حاوية ثابتة قابلة للتمرير مثل:

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

يجب أن يتم تمرير العناصر الفرعية الآن كمصفوفة ، ولكن إذا تم تمرير فئة مركبة ، فيجب أيضًا تنفيذ هذه الأنماط لتجنب كسرها. فقط يضيف طبقة من التعقيد. لكن يمكنني أن أفهم تمامًا مدى تعقيد إجراء التغيير. مجرد رمي قبعتي للحصول على الدعم.

لدي حالة استخدام أخرى وصفتها بالتفصيل هنا # 3415. لكن يمكنني حلها في الوقت الحالي وأدرك أنه صعب التنفيذ ونادر.

لا أعرف شيئًا عن ردود الفعل الداخلية (حتى الآن) ، لكنني سأطرح فكرة فقط عن كيفية تمييز هذه العناصر / الأجزاء الأصلية الافتراضية في DOM: التعليقات. على سبيل المثال

<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 كأطفال من كل شيء. (بما في ذلك رد الفعل المتداخل حتى لا يتعارض مع ب و هـ). لقد رأيت أطرًا أخرى "تسيء استخدام" التعليقات لهذا النوع من الوظائف الدلالية.

Prinzhorn أعتقد أنك قد تخلط بين ناتج DOM و JSX الخاص بـ React.

في حال كان ذلك مفيدًا: اقتراحPrinzhorn باستخدام تعليقات HTML لتعيين "مكونات الأجزاء" إلى DOM هو نفس الأسلوب الذي يستخدمه Knockout. الضربة القاضية تسمي هذه "العناصر الافتراضية".

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

(من مستندات خروج المغلوب )

أيضًا ، حالة استخدام أخرى لهذا - يمكن أن تكون عناصر التغليف الإضافية مشكلة عند استخدام flexbox.

aldendaniels موافق تمامًا ، لقد واجهت مشكلات Flexbox بالفعل.

واجهت هذا مع flexbox مع القوائم المنسدلة التابعة. حيث سيعرض A ويدير القائمة المنسدلة الأولى ، متبوعًا بـ B أو C أو D اعتمادًا على قيمة القائمة المنسدلة A ، والتي من شأنها أن تعرض العدد المناسب من القوائم المنسدلة ، على سبيل المثال

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

A و B و C و D عديمة الحالة ، لذا قمت بتغييرها من class B {render(){ this.props }} إلى function B(props){ return [...]; } .

في هذه الحالة ، لا يهم الوالد كثيرًا أن يتم عرض العديد من الأطفال ، إنه فقط للتعامل مع CSS الخاص بي. هناك أشياء كنت سأفعلها بشكل مختلف إذا لم تكن بحاجة إلى إعادة استخدامها (يحتاج المكون الآخر إلى B و C و D).

كبديل ، ربما وسيلة للتخلص من الوالد؟ ليس لدي أي أفكار محددة لكيفية ظهور ذلك.

لقد عثرت اليوم على سيناريو أعتقد أنه حالة استخدام جيدة لهذه الميزة: مكون يعرض عدة عناصر <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>
)
...

واجهت أيضًا بعض مشكلات flexbox. لا يوجد شيء لا يمكن حله في CSS ، ولكن أحد "مزايا" flexbox هو أنك تحتاج إلى عناصر "مجمعة" أقل في كل مكان لجعل التخطيط الخاص بك يعمل ، ولكن ستظل في نهاية المطاف مع عناصر مجمعة في كل مكان عند استخدام React منذ ذلك الحين تقوم دائمًا بلف كل ما تعيده في div / div أو ما شابه ذلك ، ما لم يكن من المنطقي أن يكون لديك حاوية.

بالنسبة لجميع حالات الاستخدام المعروضة هنا ، أنا متأكد تمامًا من أنه يمكنك استبدال <BunchOfComponents /> بـ {getBunchOfComponents()} وسيكون الناتج المرئي هو نفسه ، دون تقديم المشكلات العملية والتقنية المتعلقة بالحصول على مكونات مع شظايا كجذر.

syranide ولكن في كل مرة يغير فيها أحد المكونات ، يحتاج جميع أشقائه إلى إعادة الحساب ...

أيضًا إذا كنت تستخدم coffeescript عاديًا ، فمن السهل إرجاع مصفوفة ، لذا يرجى فصل الوظيفة عن تمثيل jsx.
IOW إذا كان من السهل التعامل مع مجموعة من العناصر المرتجعة ، فلا تنتظر حتى يتمكن jsx من اللحاق بالركب.

syranide ولكن في كل مرة يغير فيها أحد المكونات ، يحتاج جميع أشقائه إلى إعادة الحساب ...

wmertens نعم ، ولكن في كثير من الأحيان ستحصل على ذلك على أي حال لأن الوالد سيحتاج إلى إعادة العرض لأسباب أخرى ، أو ببساطة لأنك تتلقى البيانات من خلال الدعائم على أي حال. لكن نعم ، هذا هو الاختلاف ، لكن هذا لا يعني أن هذا النهج صحيح ، إنه تحسين وهناك العديد من الطرق لتحقيقها.

أيضًا إذا كنت تستخدم coffeescript عاديًا ، فمن السهل إرجاع مصفوفة ، لذا يرجى فصل الوظيفة عن تمثيل jsx.

هذا غير ذي صلة وهذه ليست مشكلة مع JSX. المشكلة الكبيرة هي أنك تفقد الافتراض الفني والعملي والبديهي لمكون واحد = عنصر / عقدة واحدة . لا يمكنني التحدث باسم المطورين لكنني لن أتخلى عن ذلك عن طيب خاطر ، إنه افتراض مفيد للغاية. أنا متأكد من أن هناك تحسينات جيدة أو أفضل يمكن تصميمها إذا كان التحسين هو السبب الوحيد وراء رغبة الناس في ذلك.

syranide المشكلة الأكبر هي أنه لا يمكنك دائمًا استخدام الغلاف
عنصر في لغة تأشير النص الفائق مثل الجداول والقوائم والفليكس بوكس ​​والرأس ... العمل
هذا يؤدي إلى رمز قبيح.

سأكون سعيدًا تمامًا بعنصر غلاف افتراضي يتم عرضه فقط
التعليقات ، على النحو المقترح من قبل.

في الجمعة ، 29 مايو 2015 ، 3:56 مساءً Andreas Svensson [email protected]
كتب:

syranide https://github.com/syranide ولكن في كل مرة واحدة من
المكونات تغير كل أشقائها بحاجة إلى إعادة حساب ...

wmertens https://github.com/wmertens نعم ، لكن مرات عديدة تريد ذلك
الحصول على ذلك على أي حال لأن الوالد سيحتاج إلى إعادة العرض للآخرين
الأسباب ، أو ببساطة لأنك تتلقى البيانات من خلال الدعائم على أي حال. ولكن
نعم ، هذا هو الاختلاف ، لكن هذا لا يعني أن هذا النهج صحيح ،
إنه تحسين وهناك العديد من الطرق لتحقيقها.

أيضًا إذا كنت تستخدم coffeescript عاديًا ، فمن السهل إرجاع مصفوفة ، لذا من فضلك
افصل الوظيفة عن تمثيل jsx.

هذا غير ذي صلة وهذه ليست مشكلة مع JSX. هذا هو الموضوع الكبير
تفقد الافتراض التقني والعملي والبديهي لأحد
المكون = عنصر واحد / عقدة_. لا يمكنني التحدث باسم المطورين ولكني لا أفعل
التخلي عن ذلك عن طيب خاطر ، إنه افتراض مفيد للغاية. انا متاكد
هناك تحسينات جيدة أو أفضل على حد سواء يمكن أن تكون التصميم إذا
التحسين هو السبب الوحيد وراء رغبة الناس في ذلك.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/facebook/react/issues/2127#issuecomment -106810565.

fwiw ، من السهل نسبيًا اختراق مكون "جزء" في React يتم التعامل معه كمصفوفة من العناصر الفرعية بواسطة React. سيقوم بإنشاء المفاتيح تلقائيًا ، ولكن نظرًا لأنه يحدث بعد التحقق الأولي من صحة المكونات ، فلن يؤدي ذلك إلى ظهور الخطأ المعتاد "عدم توفير مفاتيح".

مع ذلك ، فإن هذا الاختراق يحل فقط ما كان يتحدث عنه gaearon أعلاه - عدم الاضطرار إلى التعامل مع بناء جملة مجموعة قبيحة / تعيين مفاتيح عشوائية في JSX الخاص بك - وليس مشكلة إعادة عقد متعددة في جذر طريقة تصيير المكون.

لدي مشكلة مع فكرة أن المكون يحتاج إلى إرجاع "عنصر / عقدة" واحدة. بالنسبة لي ، يبدو أنه من المعقول تمامًا استخدام بنية JSX المكونة من:

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

لينتهي به الأمر كـ DOM:

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

لا أعتقد أن هذا يعد انتهاكًا لمبدأ المفاجأة لأن المكونات تقوم بالفعل بجميع أنواع "الأشياء المفاجئة" باستخدام DOM باستخدام خطافات دورة الحياة (انظر فقط إلى نمط الثقب الدودي الشائع). من المقبول عمومًا أن المكون لن يؤدي بالضرورة إلى إنشاء عنصر واحد ، ولا بأس بذلك ، لأنه يجب إجراء بعض التنازلات للعمل مع DOM.

لا يتعلق الأمر بـ "التحسينات" ، أو حتى عدم الإعجاب ببنية المصفوفة. كما ذكر العديد من المستخدمين ، _ تكسر عناصر الغلاف التصميم والتخطيط بطرق جادة_. الجداول هي الأكثر وضوحًا ، لكن Flexbox هي أيضًا مشكلة رئيسية. لدي بالفعل CSS أعاد تطبيق القواعد المرنة لتضمين العناصر الموجودة فقط بسبب React ، وهو أمر قبيح للغاية.

بالنسبة لجميع حالات الاستخدام المعروضة هنا ، أنا متأكد من أنه يمكنك استبدالها مع {getBunchOfComponents ()} والإخراج المرئي سيكون هو نفسه ، دون تقديم المشكلات العملية والتقنية المتعلقة بالحصول على مكونات ذات أجزاء كجذر.

يتطلب هذا من المطورين التنازل عن صنع مكونات معزولة قابلة لإعادة الاستخدام - تساعدهم الجنة إذا قرروا أنهم يريدون إعادة استخدام مجموعة مكوناتهم في مكان آخر - بسبب مشكلة تنفيذ أساسية في React. لا أعتقد أنه ينبغي قبول ذلك.

تضمين التغريدة

تحرير: خطئي ، لقد خلطت بعض حججك مع مناقشة الجدول أعلاه ، وأنا أتفق إلى حد كبير مع ما تقوله على ما أعتقد. ولكن لا تزال هناك مشكلات في كون المكونات غير شفافة ، لذا فإن ما يُقصد به أن يكون غلافًا شفافًا مفيدًا يصبح معتمًا للوالدين. تخيل أن <Wrapper1><Wrapper2>...</Wrapper2></Wrapper1> ، Wrapper1 لا يمكنه رؤية أطفال Wrapper2 . لذلك ربما يكون wrapMyElements(...) ببساطة حلاً أفضل شامل لا يزال (بما في ذلك أي وظائف دعم ضرورية أخرى).

لدي مشكلة مع فكرة أن المكون يحتاج إلى إرجاع "عنصر / عقدة" واحدة. بالنسبة لي ، يبدو أنه من المعقول تمامًا استخدام بنية JSX المكونة من:

المكونات هي أكثر من مجرد أغلفة غبية ، لها غرض. IMHO يبدو أن إرجاع عناصر متعددة يمنع بعض التوقعات المفيدة للغاية. على سبيل المثال ، سيحصل React.render على رفيق في المستقبل يعرض عنصرًا ويعيد العقد ، وهذا يجب أن ينتج الآن مصفوفة من العقد بدلاً من ذلك.

لكنني أعتقد أن القضية المهمة جدًا هي مسألة قابلية القراءة والتي تعد IMHO أكبر نقطة بيع لـ React ، فكل شيء واضح.

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

بالنظر إلى هذا لا معنى له ، من أين تأتي الخلية الثالثة؟ ربما يكون هذا خطأ في الواقع ويتم عرض 2 أو 4 خلايا ، من يدري ، ربما تكون ديناميكية بالفعل وتعتمد على دعامة أو حالة خارجية؟ هناك العديد من الأشكال المختلفة لهذه المشكلة والتي لا تتطور إلا عندما تفكر في الواجهات الأمامية الأخرى التي لا تنتمي إلى HTMLDOM والتي قد يكون لها توقعات واضحة. شيء آخر يجب مراعاته هو أن العناصر غير شفافة ، لذلك إذا استبدلت <tr /> بـ <MyMagicalTr /> ، فلن يكون قادرًا على التفاعل مع الخلايا الفردية أو حتى استنتاج عدد العناصر الموجودة ، لذلك على الرغم من <MyMagicalTr /> قد يقبل فقط <MyMagicalTd /> وليس هناك ما يضمن أنه يمكنه التفاعل معهم بالفعل.

يتطلب هذا من المطورين التنازل عن صنع مكونات معزولة قابلة لإعادة الاستخدام - تساعدهم الجنة إذا قرروا أنهم يريدون إعادة استخدام مجموعة مكوناتهم في مكان آخر - بسبب مشكلة تنفيذ أساسية في React. لا أعتقد أنه ينبغي قبول ذلك.

"هذا يتطلب من المطورين التنازل عن إنشاء ..." ، ولكن هذه هي المشكلة بالضبط إذا سألتني ، إذا كان بإمكان أحد المكونات إرجاع عناصر متعددة لم يعد معزولًا ، فقد تم استبداله ، ويتسرب المكون إلى الأصل.

المسامير مطرقة. كونها قضية تنفيذ أساسية هي قضية منفصلة عما إذا كان ينبغي فعل ذلك على الإطلاق أم لا. هذا ليس قراري ، لكنني لا أرى كيف أن حالة الاستخدام النادرة هي حجة مقنعة دون النظر في المفاضلات التي تأتي معها أو ما هي الحلول البديلة الأخرى الموجودة.

IMHO لا أرى مشكلة مع {getBunchOfComponents()} ، إنها صريحة ، تسمح لنا بالحفاظ على توقعاتنا المفيدة. إذا كان الأداء يمثل مشكلة ، فإن React.createSmartFragment() (أو w / e) للإنقاذ ، وهو نوع يشبه المصفوفة / الكائن الشفاف ولكن يمكن تحديثه بشكل مستقل عن الأصل.

مرة أخرى ، فإن مطوري React هم السلطة (وليس أنا) ، لكنني لا أرى حجة مقنعة هنا بالنظر إلى الآثار الجانبية المختلفة. لست متأكدًا حتى من أنني أتفق مع الحل المقدم باعتباره نمطًا جيدًا على الإطلاق ، حتى لو كان مدعومًا.

تحرير: للتوضيح ، ربما تكون المكونات قادرة على إرجاع عناصر متعددة في المستقبل لأن هناك حالات استخدام مفيدة أخرى بشكل واضح ، خاصة في سياق المرور عبر الأطفال (مثل الحالة التي تعرضهاthomasboyt) ، يتم الحفاظ على قابلية القراءة.

أعتقد أنني سأحتاج إلى المزيد من القهوة قبل أن أتمكن من الرد على الجانب الفلسفي من هذه المحادثة (شكرًا على النقاط الجيدة جدًا ،syranide) ، ولكن من ناحية التنفيذ ، بدأت في البحث في هذه الليلة الماضية لأرى كيف تغيير قابل للتطبيق في هذا النطاق يؤدي إلى هذا الارتفاع: https://github.com/facebook/react/compare/master...thomasboyt : جزء

وألقيت عرضًا توضيحيًا صغيرًا هنا: http://www.thomasboyt.com/react-fragment-demo/

بعض الملاحظات على جانب التنفيذ من الأشياء:

• ليس من المستغرب ، أنه من الصعب جدًا تعديل نظام يتوقع أن يدعم "مكون واحد = عقدة واحدة" المزيد من العقد ؛)
• فكرت في البداية في محاولة تتبع الأجزاء على جانب عمليات DOM ، بحيث تظل تعليمات الطفرة التي تم إنشاؤها بواسطة ReactMultiChild كما هي وتعالج الأجزاء مثل أي عقدة أخرى. لم أستطع التفكير في طريقة جيدة لإضافة حالة حول عدد العقد / العقد التي هي أجزاء في تتبع حالة DOM. يمكن أن ينجح شيء مثل التعليقات المبارزة Prinzhorn ، ولكني حذر من أي شيء قد يتطلب البحث في DOM ، مع الأخذ في الاعتبار التكلفة النسبية.
• مع إهمال هذه الفكرة ، أضفت الحقل _nodeCount لجميع العناصر الفرعية لمكوِّن ReactMultiChild ، بحيث يمكنه تتبع عدد العقد الجذرية التي يحتوي عليها الجزء فعليًا.

تكمن المشكلة في أنه في حين أن هذا سهل بما يكفي لإجراء تصيير أولي من خلال عد الأطفال فقط للجزء ، فإن تحديث عدد عقدة الجزء على الطفرات اللاحقة يبدو أكثر صعوبة. لم يتم ذلك بعد في الفرع الخاص بي (انظر https://github.com/thomasboyt/react/issues/2).

• تعتمد العديد من عمليات DOM على الوصول إلى العقدة الأصلية للعنصر ، والتي تم البحث عنها بواسطة معرّف العقدة الداخلي ، لإلحاق / نقل / إزالة العناصر (راجع https://github.com/thomasboyt/react/issues/3). نظرًا لأن دورة مكون التحديث ReactMultiChild هي المسؤولة عن تمرير هذا المعرف ، يمكن تغييره لإجراء بحث عن أقرب والد لديه عقدة DOM ، ولكن هذا يبدو باهظ الثمن. بدلاً من ذلك ، قد يكون من الممكن أن يكون لديك سجل داخلي لمفاتيح الأجزاء لمفاتيح "العقدة الحقيقية".

ما زلت غير مقتنع بأن طلب الأجزاء للحفاظ على عدد العقد الجذرية الخاصة بهم هو أفضل طريقة للقيام بذلك (على الرغم من أنه قد أوصلني إلى هذا العرض التوضيحي على الأقل) ، وقد تم اختراق كل هذا معًا بسرعة كبيرة وفي وقت متأخر جدًا من الليل ، لذلك إذا كان لدى أي شخص آخر اقتراح للتنفيذ ، فلا تتردد في الاتصال بـ:>

thomasboyt IIRC تأتي عقبة التنفيذ الرئيسية من إشارة React إلى العقد الفرعية بمقدار mountIndex ، وهذا لا يعمل عندما تصبح "العقدة" فجأة أي عدد من العقد وقد يحدث هذا دون استدعاء الوالد وقد يحدث ذلك أيضًا عدة مكونات عميقة (التفاف). إذا لم أكن مخطئًا ، فمن السهل جدًا أن تدعم React عناصر جذر متعددة طالما أن الرقم لا يتغير أبدًا.

لذلك لا أعتقد أنه سيكون من الصعب بشكل خاص جعلها تعمل في React ، لكن الحل المناسب حقًا يمثل مشكلة أكثر ويجب أن يتضمن إسقاط mountIndex .

syranide الحق ؛ يقدم الحل الذي أعمل عليه في الواقع nodeIndex جديدًا من المفترض أن يكون "التعويض الحقيقي" للعقدة (وهو ما يذكرني بأنني بحاجة للعودة وإزالة mountIndex ، منذ ذلك الحين أعتقد أنه غير مستخدم الآن في فرعي).

ولكن ، كما لاحظت ، يعد هذا مشكلة إذا تغير عدد العناصر الجذرية ، حيث يلزم تحديث nodeIndex للمكون كلما تغير عدد عقدة مكون شقيق سابق. ما زلت بحاجة إلى إيجاد حل لذلك.

لقد واجهت أيضًا مشكلات في flexbox. syranide ، هل يمكنك من فضلك توضيح المزيد عن الحل الذي اقترحته "getBunchOfComponents"؟ كونك جديدًا على React ، من الصعب الحصول على فكرة كاملة عن مكان تحديد هذه الوظيفة / كيفية تطبيقها.

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

كان السيناريو الذي طلبته هو محاولة الحصول على مكون يوفر عناصر <link> و <script> دون الحاجة إلى أن يصبح عارض <head> بالكامل.

لقد أضفت ملاحظة في الجزء العلوي من هذه المشكلة. يرجى قراءتها قبل التعليق. https://github.com/facebook/react/issues/2127#issue -41668009

عثرة ... لدي حاجة كبيرة لها من جانب الخادم. يعد عرض صفحات الويب الكاملة (باستثناء DOCTYPE) أمرًا معقدًا للغاية دون القدرة على عرض الأجزاء ، بسبب قسم <head> . أنا أعمل حاليًا على حل ذلك من خلال mixins وقليلًا من المنطق في العرض النهائي ، ولكن سيكون الأمر أبسط بكثير إذا كان هناك دعم لتقديم مكونات متعددة.

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>,
      ]

بالطريقة التي تستخدمها بها ، فلن تحدث فرقًا إذا تم حل هذه المشكلة.

أحتاج إلى هذه الميزة للأسباب المذكورة بالفعل ، لذا حاول تنفيذ حاوية <frag></frag> على https://github.com/mwiencek/react/tree/frag-component

التنفيذ ليس جميلًا حقًا ، ولكن إذا نجح مع الأشخاص ، يمكنني إرسال PR والسماح لمطوّري React بتمزيقها.

mwiencek يبدو أن التنفيذ لا يعمل إذا تغير عدد الأطفال في جزء ما في تحديث (_nestedChildCount تم تعيينه في mountComponent فقط)؟ هناك القليل من الخداع لجعل كل ذلك يعمل بشكل جيد. يبدو أنك حصلت على بداية جيدة بالرغم من ذلك. لقد فكرت في هذا مرة أخرى مؤخرًا وربما اكتشفت طريقة قوية لتحقيق ذلك. سأبلغ مرة أخرى إذا وجدت النجاح.

spicyj نعم ، أنت على حق ، سأحتاج إلى النظر في ذلك ...

أذكى بشدة أننا قد نرى تطبيقًا مناسبًا قريبًا ، على الرغم من ذلك. :) لا تتردد في نسخ الاختبارات من هذا الفرع إذا كانت مفيدة على الإطلاق.

spicyj أليس الطريق إلى الأمام لاستخدام createFragment وتحويل JSX إلى ذلك؟ أم أننا نريد حقا أن تكون الشظايا عناصر؟

لبناء وتوسيع التعليق الأخير لـ syranide ، يبدو أنه لا توجد حاجة لـ "Fragment API" إضافية إذا كان التصيير يسمح للمصفوفات كقيمة إرجاع. يمكن لـ JSX تحويل عناصر جذر متعددة إلى مصفوفة ، والتي ستعمل أيضًا على قيم إرجاع أي دالة أخرى. لذلك بدلاً من تقديم سطح API إضافي ، والذي يتطلب التوثيق والتعلم ، يمكن إزالة أحد قيود React.

سيؤثر هذا على الأقل على 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

لم أر هذا مذكورًا في الخيط حتى الآن ، لكنني أعتقد أن حل هذا يحسن أيضًا من قابلية التركيب. على سبيل المثال ، تخيل أن لديك شبكة حيث تريد أن تتلاشى الخلايا فيها بترتيب معين. من الناحية المثالية ، سيكون هناك مكونان قيد التشغيل هنا: أحدهما للتعامل مع التخطيط والآخر للتعامل مع الرسوم المتحركة. سيكون لديك API مثل هذا:

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

سيمكنك هذا من التبديل إلى تخطيط مختلف ، أو رسم متحرك مختلف ، دون الحاجة إلى معرفة تفاصيل تنفيذ الآخر. يتوقع GridLayout تلقي قائمة بالأطفال. FadeAnimator تلك القائمة ، ويحقن الأنماط المناسبة و / أو مستمعي الأحداث ، ويعيد القائمة الجديدة مقابل GridLayout للاستهلاك. ليس هناك سبب يدعو FadeAnimator إلى الاهتمام بتخطيط شبكة ، باستثناء أن عناصر React لا يمكنها إرجاع المصفوفات من التصيير. علاوة على ذلك ، لا توجد طريقة بسيطة لاستبدال الشبكة ، على سبيل المثال ، بتخطيط البناء ، لأن FadeAnimator مطلوب للعمل كحاوية لأطفالها.

مع القيود الحالية ، أفترض أنه يمكنك فعل شيء مثل هذا:

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

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

ولكن هذا يجعل الكود أقل وضوحًا وأكثر تعقيدًا ويصعب تكوينه.

إضافة جزء API للسماح بإعادة مكونات متعددة من العرض！
إضافة جزء API للسماح بإعادة مكونات متعددة من العرض！
إضافة جزء API للسماح بإعادة مكونات متعددة من العرض！
إضافة جزء API للسماح بإعادة مكونات متعددة من العرض！
إضافة جزء API للسماح بإعادة مكونات متعددة من العرض！
إضافة جزء API للسماح بإعادة مكونات متعددة من العرض！
إضافة جزء API للسماح بإعادة مكونات متعددة من العرض！
إضافة جزء API للسماح بإعادة مكونات متعددة من العرض！

texttechne اقتراح أفضل. بدلاً من تقديم واجهة برمجة تطبيقات إضافية ، يجب أن يتعامل رد فعل مع عناصر جذر متعددة في العرض.

أعتقد أن التعامل مع عناصر جذر متعددة في العرض سيكون صعبًا.
هذا يعني أن هناك: https://github.com/facebook/react/blob/master/src/renderers/shared/reconciler/ReactCompositeComponent.js#L1089

سيكون لديك مجموعة من العناصر بدلاً من عنصر.
نتيجة لذلك ، وبقدر ما أفهمه ، سيكون عليك الآن إنشاء مثيل لعناصر React متعددة: https://github.com/facebook/react/blob/master/src/renderers/shared/reconciler/ReactCompositeComponent.js# L471

بعد ذلك ، قم بتركيب عناصر React متعددة تم إنشاؤها: https://github.com/facebook/react/blob/master/src/renderers/shared/reconciler/ReactCompositeComponent.js#L471

والتوفيق بين جميع العلامات المنتجة بالترتيب الجيد.

أعتقد أنه يأتي مع عيوب قد لا ترغب في الالتفاف على عملية المصالحة.
هل نريد شظايا كعناصر أو شظايا مثل تركيب السكر حول التحولات؟

أعتقد أن هذا الجزء كعنصر لا بأس به ، فسنحتاج فقط إلى إنشاء نوع جديد من العقد الداخلية يشبه العقد النصية أو العقد الفارغة ، أليس كذلك؟ على الرغم من أنني لا أعرف كيف سنتعامل معهم.

على سبيل المثال ، كيف تتعامل مع حالة عدم تثبيت أحد الجذور؟ كيف تتعامل مع التحديث بشكل صحيح؟
أو كيف تدير عدة جذور داخل DevTools؟ (إجابة واضحة: إصلاح DevTools ...)

أعتقد أن الشظية هي مكون مركب. أين الاختلاف بالضبط؟
إذا انتهى بنا الأمر إلى تكرار الشفرة من أجل تنفيذ الأجزاء ، فمن الأفضل أن ننفذ بناء جملة السكر من أجل الحفاظ على "أصالة" الأجزاء الداخلية في React؟

أنا أتساءل ، لقد كنت ألعب مع React الداخلية حول سؤال Subtree (renderSubtreeIntoContainer) وأشعر أنه مرتبط إلى حد ما. عندما تريد التجسيد إلى شجرة فرعية جديدة ، فسيتعين عليك تقديم جذر جديد في الواقع. لذلك ، إذا كنا ندعم عدة جذور على مستوى الشجرة ، فهل نعرض جذورًا جديدة في كل مرة:

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

ينتج عنه استدعاء "عرض في جذر جديد".

بدلاً من مكالمة واحدة إذا استخدمنا غلافًا ، أليس كذلك؟ ماذا عن الأداء؟ بساطة؟ لأكون صادقًا ، فإن شعوري هو: لا يجب أن نتطرق إلى ردود الفعل الداخلية للتعامل مع هذا الموقف. بدلاً من ذلك ، هل يمكننا تنفيذ هذا العمل الفذ مع JSX؟ هل يمكننا تحسين بناء جملة JSX؟

(_ إخلاء المسؤولية_: لست معتادًا تمامًا على التفاعل مع العناصر الداخلية ، وقد تكون هناك بعض الأجزاء التي لا أفهمها تمامًا أو لم أفهمها. اعتذاري عن سوء الفهم.)

تحرير: تحديد / توضيح الأشياء. أيضًا ، يقوم GitHub بتنسيق رسائل البريد الإلكتروني بشكل غامض بشكل غريب ، لذلك اضطررت إلى إعادة تنسيق كتلة التعليمات البرمجية ... :-(

مرحبًا ، مساهم / ملتزم أساسي في Mithril هنا.

TL ؛ DR: الأجزاء صعبة للغاية ، حتى عندما تكون واجهة برمجة التطبيقات والأجزاء الداخلية
بسيط.

بالمناسبة ، أعرف من التجربة أنه من الصعب جدًا تنفيذه. هذه
تم طلبه أيضًا عدة مرات لـ Mithril ، لكنه رفض بسبب
الصعوبة المطلقة. فشلت كل محاولة لتنفيذه عند
فشل ثلث مجموعة الاختبار على الأقل.

ما زلت أعمل على تفاصيل حول مكتبة vdom أخطط لكتابتها ،
وسوف يتعامل مع كل شيء على أنه جزء ، ولكن هذا شيء لديك
حرفيا (إعادة) كتابة جزء العرض من الصفر لـ. مثل React ،
سيتم فصله عن DOM ، لكن واجهة برمجة التطبيقات ستختلف بشكل كبير
من الناحية المفاهيمية للعرض.

إليك مشكلة الشظايا: عليك إدارتها بالكامل
داخليًا أو أنك لا تفرق بينهما بشكل صحيح. حتى في
document.createContextualFragment عديم الفائدة. فقط كمثال ، دعنا
تحويل شجرتين ، مما يجعله محذوفًا:

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

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

يجب أن يكون التحويل الصحيح لهذا هو استبدال العناصر B C والعنصر $ # $ 3 $ # $ ، مع ترك الباقي دون تغيير. إن اكتشاف ذلك ليس بالأمر الهين ، وعليك أن تقوم بتكرار أطفال الجزء بينما تتجاهل حقيقة أنهم في جزء.

ولكن عندما يختفي الجزء ، عليك التعامل مع دلالات الخطاف ، مثل
shouldComponentUpdate (لا أتذكر اسم React لهذا الخطاف). وبالتالي
لا يزال عليك تتبع الأجزاء بشكل مستقل. أنت فرق بهم
المحتويات كما لو كانت جزءًا من جزء الوالدين ، ولكن لا يزال لديك
لتتبع موضع هذا الجزء من أجل المكون.

أو بعبارة أخرى ، لم تعد المكونات مرتبطة ارتباطًا جوهريًا بها
عقدة DOM. بدلاً من ذلك ، يتم ربطهم بالجزء المقابل. تقوم React ، مثل معظم مكتبات وأطر عمل vdom الأخرى ، بربط المكون جوهريًا بتمثيلها الشجري ، حتى مع الأنواع المتوقعة. هذه هي أسهل طريقة لتنفيذ خوارزمية فرق
يتعامل مع المكونات. عندما ينفصلان ، عليك أن تفصل بينهما
مسك الدفاتر لكليهما. لا يمكنك تهيئة المكونات عند التهيئة
العقدة. إنها الآن عمليتان منفصلتان تمامًا. من الصعب القيام بذلك
في البداية ، ومن الأصعب إضافة الدعم لما بعد ذلك.

شكرا لكم جميعا على الكلمات. نحن نعلم أن هذا صعب ولا يزال موجودًا في قائمة مهامنا. (السؤال بحماس لن يجعل ذلك يحدث عاجلاًjanryWang.)

isiahmeadows لمعلوماتك ، يدعم فرع إعادة كتابة Mithril الأجزاء.

spicyj نرحب بإلقاء نظرة على التنفيذ [1] [2] والاختبارات [1] [2] إذا لم تكن تتابعها بالفعل. يبلغ حجم محرك الفرق بالكامل حوالي 400 LOC ، لذا نأمل أن يكون من السهل متابعته

isiahmeadows أعتقد أن GitHub أكل جزءًا من تعليقك. تم كسر كتلة التعليمات البرمجية ، ولا يمكنني رؤية المثيل الأول من <D /> .

يبدو جيدًا في البريد الإلكتروني بالرغم من ذلك. ربما وجدت خطأ في GitHub؟

لسوء الحظ ، تتصرف معالجة تخفيض الأسعار في GitHub بشكل مختلف عندما يأتي تعليق من بريد إلكتروني. لقد قمت بتحرير التعليق لإزالة سطر فارغ ويظهر الآن.

قمت بإعادة توجيه البريد الإلكتروني الأصلي لدعم @ github. نأمل أن يتمكنوا من إصلاح المحلل اللغوي. 😃

lhorie هل تستخدم بنية مصفوفة للجزء؟
هل لديك بوليفيل لـ DocumentFragment؟

واستخدام عنصر غلاف "زائف" ، مثل تعليق HTML ليس خيارًا؟ اعتقدت أن هذه هي الطريقة التي يتم من خلالها "حل" العقد النصية ...

شكرًا لإصلاح هذا التعليق spicyj

لمعالجة المخاوف التي أثارهاisiahmeadows في مثاله: محرك Mithril الجديد لا يتبع الدلالات التي اقترحها isiahmeadows لعدة أسباب:

• إن تطبيق هذه الدلالات سيجعل الاختلاف ـ بشكل ملحوظ ـ أكثر تعقيدًا
• قد يجعل من الصعب التفكير بشأن المفاتيح والأخطاء المتعلقة بالمفاتيح نظرًا لأنه يصبح من الممكن أن تتسرب المساحات الرئيسية من المكونات وحتى إلى المكونات الشقيقة والمكونات الفرعية.
• سيجعل دورات حياة الجزء غير بديهية (على سبيل المثال ، في هذا المثال ، تمت إزالة B.bar ، وكذلك الجزء ، ويتم إنشاء جزء جديد لالتفاف C). هذا ينتهك المبدأ العام القائل بأن دورات الحياة "تتالي" ، مما يعني أنه لم يعد بإمكانك التأكد من إزالة العقدة الفرعية إذا تمت إزالة عقدة رئيسية معينة. مثل النقطة السابقة ، من المحتمل أن يتسبب هذا في حدوث تسرب في إمكانيات تغليف أحد المكونات.
• من الناحية الافتراضية ، إذا واجه المرء مشكلات فرق تتعلق بمحرك فرق لا يلتزم بهذه الدلالات ، فإن حل مساحة التطبيق يكون تافهًا مثل التفاف جزء حول العقدة المخالفة.

سأكون مهتمًا إذا كان بإمكان الفريق الأساسي التوسع في الملاحظة في الجزء العلوي بخصوص: _لماذا_ هذا صعب مع البنية الحالية. بالنظر إلى أن محرك العرض في React و Mithril يحاولان بشكل أساسي حل المشكلات نفسها ، وأن Mithril يدعم الآن الأجزاء إلى درجة أعتقد أنها ممكنة ومفيدة ، وربما يكون تنفيذها في React أكثر جدوى إذا كانت جوانب مختلفة من الدلالات يتم تقييمها بشكل منفصل (ومن المحتمل رفضها) كما تم إجراؤها مع Mithril.

لاحظ أنني أصلحت تعليقي. لقد ارتكبت بعض الأخطاء ، ولا يقوم GitHub بتصميم ردود البريد الإلكتروني بشكل جيد ...: عابس:

Primajin لقد تساءلت عن ذلك أيضًا ، لكنني أظن أنه سيتم تمريرهم كعنصر واحد. من المهم جعل الأجزاء قابلة للتركيب (انظر المثال أعلاه ). ومع ذلك ، ربما تكون هناك أوقات قد ترغب في معاملتها كوحدة واحدة أيضًا.

ربما ، يجب أن يقوم React.Children.map بتوسيع الأجزاء. إذا كنت تريد التكرار على كل طفل (بما في ذلك الأطفال من الأجزاء الصغيرة) ، فاستخدم Children.map . إذا كنت تريد التعامل مع الأجزاء كمربع معتم ، فاعمل مباشرةً مع props.children باعتباره {array، element}.

lhorie لم أشارك في إعادة الكتابة ، على الرغم من ذلك ، فأنا لست على دراية بتعقيداتها. لقد كنت مشغولًا بحقيقة أن لديّ واحدًا نهائيًا هذا الأسبوع وثلاثة في الأسبوع المقبل ، بالإضافة إلى أنني أعمل مع شخص ما لإعداد تدريب داخلي تتطلبه كليتي. لقد ركزت أيضًا على إنهاء Techtonic ، وهو الأمر الذي قمت به تقريبًا CLI (تم كسر اختبار لا ينبغي أن يكون).

isiahmeadows مجرد تذكير ودي للبقاء على الموضوع. لا تتردد في استخدام غرفة mithril gitter إذا كنت تريد الدردشة حول مواضيع أخرى.

تضمين التغريدة

ربما ، يجب أن تقوم خريطة React.Children.map بتوسيع الأجزاء

يقوم مستقر Mithril بعمل شيء مشابه داخليًا (أي تسطيح المصفوفات الفرعية) ، لكنني أتحرك بعيدًا عن هذا النموذج لأسباب تتعلق بالكمال (وأيضًا بسبب بعض الصداع التاريخي فيما يتعلق بقوائم vnode التي تمزج العقد ذات المفاتيح مع العقد غير ذات المفاتيح). قد يكون شيئا للنظر فيه.

واستخدام عنصر غلاف "زائف" ، مثل تعليق HTML ليس خيارًا؟ اعتقدت أن هذه هي الطريقة التي يتم من خلالها "حل" العقد النصية ...

لقد استخدمنا https://github.com/mwiencek/react-packages في الإنتاج لبضعة أشهر. يستخدم نهج غلاف التعليقات هذا ، بحيث يمكن تضمين الأجزاء بشكل لا لبس فيه.

mwiencek هل من الممكن استخدام نهجك بدون حزمة رد فعل مخصصة؟

mwiencek هل أغلفة التعليقات ضرورية؟ لا أتوقع أشياء ذكية من الأجزاء ، إذا قمت بنقل عنصر من جزء إلى جزء شقيق أو عنصر جذر ، فيمكن إعادة إنشائه.

لذا ، إذا اتبعت شجرة vdom بالترتيب ، فلن تحتاج إلى تعليقات ، أو هل أنت كذلك؟

على أي حال ، يبدو أن الحل الخاص بك هو بالضبط المطلوب لحل هذه المشكلة ، للوهلة الأولى. 👍

ليس بشكل صارم ، لكنهم جعلوا التنفيذ أبسط في هذه الحالة.

إذن ، ليس من الممكن حاليًا إنشاء قوائم وصف مناسبة <dl> باستخدام React؟

<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 ، فهل هناك أي احتمال أن يكون هذا جزءًا من React المناسب قريبًا؟ أم ننتظر المصلح الجديد؟

بالنظر إلى وجود حل عملي في https://github.com/mwiencek/react-packages

هل تستخدمه بنجاح في مشاريع حقيقية؟

تضمين التغريدة

التنفيذ ليس جميلًا حقًا ، ولكن إذا نجح مع الأشخاص ، يمكنني إرسال PR والسماح لمطوّري React بتمزيقها.

بالتأكيد ، من فضلك أرسل العلاقات العامة!

حول تقديم العلاقات العامة ، كان آخر ما سمعته من spicyj هو أنهم أرادوا إنهاء الخوارزمية الأساسية الجديدة والقيام بحل مناسب مع ذلك ، نظرًا لأن عُقد التعليق لا معنى لها حقًا في React Native. لم أتابع حالة ذلك ، لكنني لا أعتقد أن هذه الخطط قد تغيرت. يسعدني أن يجد الأشخاص الحزم مفيدة في هذه الأثناء.

الخوارزمية الجديدة قيد العمل وتدعم الأجزاء. ومع ذلك ، لا أتوقع أن يصبح الإنتاج جاهزًا لأشهر قادمة. أتساءل عما إذا كانت إضافة هذا أولاً إلى React DOM ولاحقًا إلى React Native سيئة للغاية؟ الجانب السلبي هو أنه يكسر النظام البيئي قليلاً (يقصد التورية!) ، لكنه قد يمنحنا بعض الوقت لتجربة هذه الميزة. لدينا اجتماع للفريق اليوم لذا سأطرح هذا السؤال إذا كان لدينا الوقت لفهم أفضل.

gaearon هل يمكنني الإشارة إلى أن دعم الأجزاء بسيط للغاية ، إنه مجرد سكر ، وأنا أستخدم حاليًا <frag> بنفسي عن طريق غلاف تافه صغير. هل إعادة عدة أطفال كجذر مكون أمر مهم حقًا؟

syranide أنا أستخدم البناء المخصص مع frag في بيئة بيتا ، ولكن أود استخدام بنية React الرسمية بدلاً من ذلك. هل يمكنك توفير غلاف <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 نعم ، إنه فقط لتمكين بناء جملة أكثر منطقية لإنشاء أجزاء ، ولا يضيف أي ميزات جديدة.

تضمين التغريدة
كنت أفكر فيما إذا كان من الممكن تقديم التعليق يدويًا ومعاملته كمكون آخر (قد لا يكون ذلك ضروريًا)؟
يتم التعامل مع التعليقات داخليًا على أنها من النوع #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>

وفي هذه الحالة ، ستحل React محل كل العناصر الموجودة.
هل من الممكن عمل "إضافة" دون استبدال العناصر الأخرى؟

شكرا،

@ rifton007 هذه ليست الطريقة التي يعمل بها. يمكن أن يكون لديك عناصر / مكونات متعددة مثل الأشقاء ، ملفوفة في وعاء. القيد هو أن المكون لا يمكنه return عناصر متعددة. سوف يعمل الرمز الذي نشرته للتو.

ومع ذلك ، إذا توصلت إلى مثال لا يعمل ، فمن المهذب قراءة الموضوع بالكامل والتفكير فيما إذا كنت تضيف مثالًا جديدًا أم لا تكرر نفس المشكلة التي تم الاعتراف بها بالفعل. هذا قيد معروف ، ويحتوي هذا الخيط على مناقشة موسعة للتفاصيل وأسباب التقييد. صرح دان أيضًا أنهم يعتزمون إصلاح دعم هذا ، في النهاية. ما الذي تحاول تحقيقه بالإشارة إلى مثال آخر لمشكلة معترف بها؟

عذرًا ، أردت فقط معرفة ما إذا كان لدى أي شخص حل بديل في الوقت الحالي.
يمكنك حذف مشاركاتي إذا لزم الأمر.

أقوم بإنشاء تطبيق باستخدام Framework7 و React ، ولكن تنسيق framework7 html ثابت ،

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

لا يمكنني التفاف العناصر الفرعية من المستوى الأول (شريط التنقل ، شريط البحث) في عناصر div أخرى لا تحتوي على فئة "صفحة"

لدي مكون يقوم بإرجاع قائمة من الصفوف

لمعلوماتك ، فإن إعادة الكتابة التي نعمل عليها (# 6170) تدعم بالفعل الأجزاء. يمكنك تتبع تقدمنا ​​في # 7925 وعلى http://isfiberreadyyet.com.

مجرد حقيقة أن عنصر <table> لا يمكنه عرض عناصر معينة هو سبب كافٍ لإضافة هذه الميزة لكي تكون متوافقة مع واجهات برمجة تطبيقات الويب.

تحرير: آه ، شظايا! نتطلع إليهم.

تضمين التغريدة

كما لوحظ في أول مشاركة في هذا الموضوع:

ملاحظة من المشرفين:

نحن نعلم أن هذه مشكلة ونعرف بالضبط مجموعة المشكلات التي يمكن حلها . نريد هذا أيضًا ، لكنها مشكلة صعبة في بنيتنا الحالية. التعليقات الإضافية التي تعبر عن الرغبة في هذه الميزة ليست مفيدة.

😉

يا إلهي ، يجب أن أتوقف عن فعل ذلك.

لقد قمت بالتصويت لصالح هذا ولكني أردت مشاركة حالة استخدام صالحة. افترض أن لدي 3 أزرار أريد تخطيط CSS السائل (يسار ، وسط ، يمين). يكون الزر الأيسر مرئيًا دائمًا ، لكن الاثنين الآخرين مرئيان بشكل مشروط. في React (على وجه التحديد React Native) ، أستخدم flexbox وأعرضه على النحو التالي:

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

لا يتم وضع الزرين الأوسط والأيمن بشكل صحيح لأنهما ملفوفان في عرض واحد.

نعم ، يمكنني تقسيم الزرين الأوسط والأيمن إلى طرقهما الخاصة ، لكن هذا من شأنه أن يقدم الكثير من التعليمات البرمجية الزائدة عن الحاجة نظرًا لأنها تشترك في الكثير من السلوك.

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

كما هو مذكور أعلاه ، نحن على دراية بالفعل بحالات استخدام هذه الميزة ونعمل بجد على دعمها. (يوجد بالفعل نصف دزينة من الأشخاص أعلاه ينادون بمشكلة Flexbox.) نظرًا لأنه لا يبدو أن المزيد من المناقشة ستكون مثمرة ، فأنا أقفل هذا. سنقوم بالتحديث عندما يكون لدينا أخبار حول التنفيذ الجديد.

أعتقد أنه يمكننا إغلاق هذا.

يتم دعم إرجاع المصفوفات من المكونات منذ React 16 Beta 1 والتي يمكنك تجربتها الآن .

لا تزال هناك بعض القيود (دعم SSR ليس جاهزًا) ولكننا نتتبعها في # 8854 وسنصلح قبل الإصدار السادس عشر الأخير.

شكرا للجميع على ملاحظاتك!

شكرا دان

🍾🍾🍾

🦏

تضمين التغريدة هل يدعم عقدة النص الخالص؟

نعم ، يدعم إرجاع السلاسل أيضًا.

هل لي أن أسأل كيف يفترض أن يعمل هذا؟

كنت آمل أن يسمح لنا بعرض عنصري XJS متجاورين ولكن إذا قمت بعمل return ["foo", "bar"] (شيء أكثر فائدة ؛) ، فسأحصل على bundle.js:66656 Warning: Each child in an array or iterator should have a unique "key" prop. المتوقع

فهل كانت الميزة وسيلة لعدم إحاطة قائمة حقيقية بعنصر غريب؟

فهل كانت الميزة وسيلة لعدم إحاطة قائمة حقيقية بعنصر غريب؟

نعم ، طريقة لتوفير عدة عناصر من تصيير واحد. (لمزيد من المعلومات ، راجع منشور الإصدار الأولي.)

إذا كان من المعروف أن جميع عناصر المصفوفة الخاصة بك هي سلاسل ، فقط قم بربطها وإرجاع سلسلة واحدة. إذا لم يكن الأمر كذلك ، يمكنك إما تناول هذا التحذير أو تحديد ما يجب القيام به لفهم في عناصر بحيث يمكن إدخالها لتحسين تسوية DOM ، تمامًا كما لو كنت قد قمت بتضمين مجموعة من السلاسل داخل عنصر آخر في JSX.

diligiant الإرجاع ['foo', 'bar'] ليس له صلة بهذه المشكلة. لا يمكنك أبدًا وما زلت غير قادر على فعل return <div>{['foo','bar']}</div> يجب أن يكون لكل طفل في المصفوفة خاصية "key" سواء كانت في علامة jsx داخلية مثل <div> أو تمت إعادتها. ما يمكنك فعله الآن هو:

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

يزيل قيودًا كبيرة في التفاعل.

بالمناسبة ، فإن إرجاع ['foo', 'bar'] يمنحك تحذيرًا وليس خطأ ولإزالة هذا التحذير ، يمكنك بسهولة الانضمام إلى هذه السلاسل أو إذا كانت علامات jsx وليست سلاسل ، فيمكنك إضافة خاصية رئيسية لها. لذلك ليس هناك قيود على إرجاع المصفوفات.

تضمين التغريدة
sassanh ، من المثال الخاص بك ، يبدو أنني كنت "خجولًا" جدًا لاستخدام المفاتيح "فقط" لتجنب محيط عديم الفائدة (من الناحية الدلالية) <div> . هل تقصد أنه يجب علي المضي قدمًا وأنه لا توجد عقوبة أداء حقيقية؟ سيكون ذلك بالفعل تحسنًا حقيقيًا!

diligiant أشك في أنه يقدم أي عقوبة أداء ، لكنك لست بحاجة إلى div محيط عديم الفائدة ما لم تكن محيطة بالسلاسل وإذا كانت سلاسل محيطة يمكنك تجنب المصفوفة على الإطلاق والانضمام إلى السلاسل. إذا لم تكن سلاسل يمكنك إضافة المفتاح إلى المكون. على سبيل المثال ، إذا كان لديك مكونان Foo و Bar يمكنك إرجاع [<Foo key='foo'/>, <Bar key='bar'/>] ولا تحتاج إلى إحاطة مكوناتك (كما هو الحال دائمًا) ولا المصفوفة الخاصة بك (بفضل هذا الإصدار الجديد ، كنت بحاجة إلى إحاطة المصفوفة قبل 16).

sassanh رائع بعد ذلك. بالطبع كانت حالة الاستخدام الخاصة بي مع مكونات متعددة. سعيدة!! ؛)

في الواقع يبدو غريباً بالنسبة لي أننا نحذر من فقدان المفاتيح عندما تكون جميع العناصر عبارة عن سلاسل. لا أتوقع منا أن نفعل ذلك. هل هذا السلوك موجود في العدد 15 عندما تكون السلاسل داخل div؟ إذا لم يكن الأمر كذلك ، فيجب علينا إصلاحه في 16 لسلاسل المستوى الأعلى (لأنه من المستحيل إعطاء المفاتيح لهم).

gaearon آسف ، كان المثال مضللا: قصدت المكونات.

لقد راجعت وأقل من -beta.5 ، لا يصدر React تحذيرًا عند عرض مصفوفة بسلاسل متعددة.

ومع ذلك ، أشعر بالحيرة من المتطلب key عند تقديم مصفوفة فقط من أجل تجنب المكون المحيط. أنا أفهم ولا شيء ، لكنه من المحتمل أن يثير الكثير من الأسئلة حول SO (ليس لدي شيء أفضل لأقدمه على الرغم من ...)

وأخيرا ، شكرا لك مرة أخرى.

هذا التحذير هو نفسه تمامًا كما هو الحال مع أي استخدام آخر لمصفوفات المكونات ، لأنه يتلخص في نفس "العمل الإضافي" بالضبط للمصلح ، وبالتالي نفس التحسين المحتمل بالضبط عن طريق تعيين key . بالنسبة لي ، ستكون المفاجأة إذا تم التعامل مع مصفوفات المكونات بشكل مختلف اعتمادًا على هذا ، وأتصور أن ذلك سيثير بعض أسئلة Stack Overflow أيضًا. ناهيك عن أنني أعتقد أنه سيتطلب بعض النفقات العامة فقط لتتبعها في المقام الأول.

.. وفي معظم الأوقات سأقوم بإرجاع مصفوفة من دالة ، أريد أن يكون التحذير key في مكانه. يبدو أن الأوقات التي لا تريد فيها التحذير هي الأقلية ، ولا توجد طريقة لكي تعرف React ما إذا كان من المناسب عدم التحذير.

التحذير ضروري لأن نقص المفاتيح يمكن أن يسبب مشاكل في الصحة ، وليس فقط مشاكل في الأداء. يتم شرح ذلك في العديد من القضايا الأخرى التي تسأل عن سبب أهمية المفاتيح ، لذا أشجعك على البحث عنها وقراءة تلك المناقشات. أوافق على أن المستندات يمكن أن تكون أكثر وضوحًا حول هذا الأمر ، وهذا شيء من المحتمل أن ننظر إليه في المرة القادمة التي نجري فيها سباق سريع لتغيير المستندات.

لا توجد فروق مفاهيمية بين المصفوفات التي تم إرجاعها مباشرة من التصيير ، والمصفوفات داخل div. لذلك لا يوجد سبب لوجود تحذير رئيسي في حالة واحدة دون الأخرى. يحتاجون إلى العمل بنفس الطريقة لأن كلاهما يتأثر بنفس المشاكل عند فقد المفاتيح.

ومع ذلك ، فإننا نتفهم أنه من المزعج تحديد مفاتيح للمحتوى الثابت . تمامًا مثلما لا تحدد المفاتيح عند كتابة بنية JSX حيث يكون الأطفال معروفين بشكل ثابت (وبالتالي لا يعيدون الترتيب أبدًا) ، سيكون من الجيد أن يكون لديك طريقة للقيام بذلك باستخدام المصفوفات.

قد نحل هذه المشكلة في المستقبل عن طريق إضافة دعم صريح للأجزاء في JSX بصيغة مثل:

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

يمكن أن ينتج مصفوفة ولكن يعين ضمنيًا فهارس رقمية للأطفال لأننا في هذه الحالة نعلم أنه لا يمكنهم إعادة الترتيب أبدًا. هذا الضمان الذي يقدمه تعبير الطفل JSX هو بالضبط ما يتيح لنا الابتعاد دون تحديد المفاتيح في كود JSX العادي حيث قد يكون لل div عدة أطفال.

لكن ليس لدينا بناء الجملة هذا حتى الآن. حتى الآن هذا قيد معروف.

JesperTreetop & zwily ، gaearon أوضح الأمر بطريقة أفضل مما فعلت ؛)

بمجرد أن تعرف ، هذه ليست مشكلة كبيرة ولكن بما أننا جميعًا نريد أن تزدهر React ، كنت أقول ...

gaearon هل هناك مشكلة أخرى لاقتراح بناء الجملة <> يمكننا مشاهدتها بدلاً من إجراء مزيد من المناقشة حول هذه المشكلة؟ لقد بحثت في جميع الأنحاء ولكني لم أتمكن من العثور على واحد.

smrq +1 للسؤال - أتابع كل شيء عن تلك القيود المحرجة (نتيجة واحد لواحد rendrer() ، مفاتيح وبناء جملة JSX أو أجزاء) ولكن التذكرة الوحيدة التي أعرفها هي https://github.com/ فيسبوك / jsx / قضايا / 65

أفترض أيضًا أن الألياف ستصلح مشكلة المفاتيح على الإطلاق - لكن يبدو أنه حلم لم يتحقق

المفاتيح ليست "مشكلة". :) إنها جزء أساسي وضروري من أي إطار عرض يسمح لك بإنشاء قوائم ديناميكية.

راجع https://facebook.github.io/react/tutorial/tutorial.html#keys للحصول على شرح أكثر تفصيلاً.

spicyj في الواقع إنها «مشكلة» لأنها تسبب إنفاقًا ممتدًا للطاقة من المطورين وهناك إمكانية أساسية لبرمجة إطار العرض دون مثل هذا المطلب (على سبيل المثال https://github.com/dfilatov/vidom)

هناك إمكانية أساسية لبرمجة إطار العرض دون مثل هذا المطلب (على سبيل المثال https://github.com/dfilatov/vidom)

لا تستخدم vidom المفاتيح في المجموعات بالرغم من ذلك. قد يعمل بدونه من الناحية الفنية ولكن من المحتمل أن يكون أبطأ بكثير. يمكن أن تعمل React أيضًا تقنيًا بدون مفاتيح ، ولكن سيكون من غير المتوقع تمامًا أن تجد أنه يجب تحديث نصف مكوناتك عند إزالة عنصر واحد من القائمة. باستخدام المفاتيح ، لا يتم تثبيت سوى عنصر واحد.

يمكن لـ @ goto-bus-stop vidom استخدام المفاتيح ، لكنها غير مطلوبة وبدونها فقط الحالات الكبيرة حقًا مع الكثير من التحديثات يمكن أن تسبب مشاكل حقيقية في الأداء

لذلك أعتبر هذا الجزء اختياريًا (على سبيل المثال ، shouldComponentUpdate ) والذي يمكن استخدامه لتعديل الأداء في الحالات الفردية

veged مثال على vidom تكافح بدون مفاتيح .

ليس لديه فكرة أنه من المفترض إعادة ترتيب العناصر ، لذلك يتجاهل المثيلات في كل عرض لمكوِّن الجذر.

كشخص على دراية بفضاء النطاق الافتراضي [1]. أستطيع أن أقول ذلك:

1. تعتبر المفاتيح ضرورية لتحديثات الحالة والحالة التي يمكن التنبؤ بها بين الأشقاء المماثلين.
2. المفاتيح ليست عادةً تحسينًا ، وفي الواقع - تكون عكس ذلك عادةً.

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

ومع ذلك ، فإن المشكلة الواضحة هنا (كما وصف gaearon ) هي استخدام ثابت تمامًا للمصفوفات والفرق بين المصفوفات الثابتة وأجزاء JSX الثابتة

ليس لدى brigand O أدنى شك في أن إعادة ترتيب المكونات كاملة الحالة قد يتسبب في بعض المشكلات ؛-) ولكن يجبر كل الحالات الأخرى (في رأيي المزيد منها) على الكفاح من أجل هذا ... يبدو مثيرًا للجدل

المفاتيح مهمة للتفاعل. حتى لو لم يبدو أنها مهمة في بعض الحالات (على سبيل المثال لأن المكونات أدناه كلها عديمة الحالة) فلا يوجد ما يمنعك أنت أو أي شخص آخر في الفريق من إضافة مكون ذي حالة (أو حتى إدخال DOM عادي) في مكان ما على مستويات قليلة أدناه في غضون أشهر قليلة. بحلول ذلك الوقت ، قد تنسى أنه ليس لديك مفاتيح ، وبالتالي قد تتسبب إعادة الطلب في ربط الحالة (أو قيمة الإدخال) بعنصر خاطئ.

هذا هو السبب في أننا نشجعك على تحديد مفاتيح في كل مكان للقوائم الديناميكية. يؤدي عدم القيام بذلك إلى أخطاء يصعب تتبعها ، ونعتقد أنه من الأفضل قضاء عشر ثوانٍ إضافية في تحديد المفتاح بدلاً من عشر ساعات في تصحيح الأخطاء في سبب تعطل حالة مكون عدة مستويات أدناه في بعض الحالات الجانبية.

أوافق تمامًا على أنه من غير الملائم تحديد المفاتيح عندما يكون من المعروف أن القائمة ثابتة ولا تعيد ترتيبها مطلقًا. نرحب بك لمناقشة هذا الأمر في JSX repo. إذا لم تتمكن من العثور على مشكلة لهذا ، فنحن نرحب بك لإنشاء مشكلة جديدة هناك.

نظرًا لأن هذا الموضوع يحتوي على الكثير من المشتركين وتم تنفيذ الميزة ، أود قفلها لتجنب إرسال رسائل بريد إلكتروني عشوائية إلى الكثير من الأشخاص. آمل أن تعالج التوضيحات أعلاه مخاوفك ، ولكن إذا لم يكن الأمر كذلك ، فنحن نرحب بك لإنشاء عدد جديد لمزيد من المناقشة حول موضوع معين.

أنشأ smrq مشكلة اقتراح لـ <> بناء الجملة على jsx repo: https://github.com/facebook/jsx/issues/84.

لقد أصدرنا للتو دعمًا لتصدير React.Fragment # $ 0 $ # $ جديد وبناء الجملة المرتبط بـ <> :
https://reactjs.org/blog/2017/11/28/react-v16.2.0-fragment-support.html