React: [المظلة] إطلاق الإثارة

كشف unstable_AsyncMode (ربما؟)

أليس هذا مكشوف بالفعل ؟

قصدت إزالة unstable_

إنني أتطلع إلى فتح مصدر مكتبة تقسيم الشفرة غير المسماة 💯

ماذا تعني [مظلة]؟ 🤔☂️

هذا يعني أنها ميزة تؤثر على العديد من المشاريع / الحزم / الأدوات.

ghoullier أرى ، شكرا جزيلا لك!

مرحبًا acdlite ، مجرد سؤال حول أفضل طريقة للاستعداد لذلك. لا تسأل عن / تتوقع أي نوع من الجدول الزمني ، ولكن أتساءل:

هل تتوقع حاليًا أن تسقط هذه الميزات في React 16 وأن يكون من السهل اعتمادها بشكل تدريجي ، مثل واجهة برمجة تطبيقات السياق الجديدة التي وصلت إلى 16.3؟

أم أنك تعتقد أنه سيكون شيئًا يدفع React إلى الإصدار 17 ويتطلب المزيد من العمل لتبنيه؟

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

هل لديك أيضًا أي نصائح حول أفضل طريقة للتحضير (من حيث الكود المكتوب اليوم ، والذي يريد أن يكون متوافقًا في المستقبل مع هذه التحسينات على React) - polyfill / التقنيات / إلخ؟

(أعتذر إذا تمت الإجابة على هذه الأسئلة في مكان آخر وفاتتني)

إضافة سؤال آخر إلى أسئلة JedWatson :

• كما أننا لا نحتاج / نتوقع الحصول على جدول زمني لإصدار مستقر ، ولكن هل سيكون من الممكن / المفيد الحصول على إصدار تجريبي جديد؟ (أحدث إصدار من AFAIK هو 16.4.0-alpha.0911da3 من فبراير.)

شكرا لك! ❤️

IMO ، سيقدمون منشور مدونة كما كان من قبل قبل هبوطه.

وأعتقد أنك لست بحاجة إلى التحضير كثيرًا لأنه لا يوجد تغيير فاصل (يحتوي على العديد من الميزات التي ربما تبدو مختلفة / تتعارض مع الممارسات الحالية ، مثل إحضار الإعادة مع التشويق ، ولكن سيكون هناك كود كود أو تغليف سهل للقيام بذلك ، كما تعلم ، يحتوي fb على مكونات 3W +). وإذا شاهدت حديث acdlite (حول تشويق SSR في ZEIT ) و فستعرف أنك لست بحاجة إلى القلق بشأن الكثير وأنه ليس غازيًا.

بالمناسبة ، يمكنك فقط البحث عن مفتاح "Umbrella" في الريبو وستجد المزيد من المعلومات مثل # 8830 و # 12152

AFAIK الإصدار الأحدث هو 16.4.0-alpha.0911da3 من فبراير.

IIRC ، هذا خطأ في التشغيل؟

JedWatson ساعدني هذا التعليق في فهم ما يجب على المطور فعله للمساعدة في ضمان أمان تطبيقاتهم غير المتزامن .

أنا أعمل على طرح وحدة التشويق وواجهات برمجة التطبيقات الجديدة في facebook. في حالة انشغالacdlite بشيء آخر ، أود مشاركة بعض أفكاري حول تجربتنا في facebook والإجابة على بعض أسئلةJedWatson.

هل تتوقع حاليًا أن تسقط هذه الميزات في React 16 وأن يكون من السهل اعتمادها بشكل تدريجي ، مثل واجهة برمجة تطبيقات السياق الجديدة التي وصلت إلى 16.3؟

لست متأكدًا مما إذا كان سيأتي مع React 16 أو 17. وفقًا لفريق React ، فمن المحتمل أن يتم إصداره قبل نهاية هذا العام ، والذي يعتمد على مدى جودة تشغيله في facebook وكيف تكون واجهة برمجة التطبيقات ذات الصلة جاهزة أو ليس. لكن من ناحية الكود ، يسعدني أن أقول إنه سيكون من السهل اعتماده ، لأننا نجرب منذ فترة طويلة في facebook. ستظل ميزة التعليق تعمل لقاعدة التعليمات البرمجية الموجودة. ولكن مع تغييرات إضافية (مثل العرض غير المتزامن) ، سيكون لديك المزيد من المكافآت التي ستجلبها لك الميزة الجديدة.

هل لديك أي نصائح حول أفضل طريقة للتحضير (من حيث الشفرة المكتوبة اليوم ، والتي تريد أن تكون متوافقة في المستقبل مع هذه التحسينات على React) - polyfill / التقنيات / إلخ؟

أود أن أقول إن الهجرة تدريجية وتدريجية إلى حد ما. مثل @ NE-SmallTown قال ، لا نريد إدخال أي تغييرات عاجلة. سيكون من المؤلم أيضًا طرحه على Facebook لأن لدينا قاعدة بيانات كبيرة جدًا. ولكن حتى الآن ، كان النشر سلسًا ولا يتطلب منك إجراء تغييرات إضافية.

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

هل تتوقع حاليًا أن تسقط هذه الميزات في React 16 وأن يكون من السهل اعتمادها بشكل تدريجي ، مثل واجهة برمجة تطبيقات السياق الجديدة التي وصلت إلى 16.3؟

بشكل تدريجي. دائمًا بشكل متزايد :) وإلا فلن نتمكن من شحن هذا على Facebook.

هذا ما أتوقعه:

| | العميل | عرض جانب الخادم |
| ----------------- | ---------------------------- | - -------------------------------------------- |
| تشويق | يعمل في كل مكان * | نفس القيود الموجودة في عارض الخادم |
| عرض غير متزامن | الاشتراك باستخدام <AsyncMode> | نفس القيود الموجودة في عارض الخادم |

* في وضع المزامنة ، يكون delayMs دائمًا 0 . تظهر العناصر النائبة على الفور.

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

لذا فإن الفكرة هي أن المستخدمين سيبدأون في الترحيل إلى Suspense حتى قبل أن يكونوا مستعدين للترحيل إلى العرض غير المتزامن. ثم بمجرد أن تصبح الشجرة الفرعية جاهزة ، يمكنهم الاشتراك عن طريق الالتفاف بـ <AsyncMode> .

بالنسبة للتطبيقات الجديدة ، فإن القصة مختلفة: الانتقال غير المتزامن افتراضيًا. سنقدم واجهة برمجة تطبيقات جذر جديدة (بديل لـ ReactDOM.render ) غير متزامن فقط.

ستكون هناك فترة غير ملائمة بعد الإصدار الأولي حيث قد لا تعمل العديد من أطر العمل التابعة لجهات خارجية (Redux و Apollo و React Router ...) بشكل صحيح في الوضع غير المتزامن. قد يضر ذلك التبني لفترة من الوقت. لكن الفكرة هي أن الميزات الجديدة ستكون مقنعة للغاية بحيث لن يستغرق الأمر وقتًا طويلاً للمكتبات للتكيف أو استبدالها ببديل متوافق غير متزامن.

هل لديك أيضًا أي نصائح حول أفضل طريقة للتحضير (من حيث الكود المكتوب اليوم ، والذي يريد أن يكون متوافقًا في المستقبل مع هذه التحسينات على React) - polyfill / التقنيات / إلخ؟

لف كل شيء <StrictMode> وتأكد من عدم وجود تحذيرات. سيكون لدينا أدلة ترحيل أكثر تفصيلاً كلما اقتربنا من الإصدار.

ستكون هناك فترة غير ملائمة بعد الإصدار الأولي حيث قد لا تعمل العديد من أطر العمل التابعة لجهات خارجية (Redux و Apollo و React Router ...) بشكل صحيح في الوضع غير المتزامن.

أبولو لا يفعل شيئًا غريبًا - سنكون مستعدين! 🕺😳

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

سأتناغم وأقول إن فريق Redux يعمل على التوافق غير المتزامن لـ React-Redux.

لقد وضعت خارطة طريق محتملة على https://github.com/reduxjs/react-redux/issues/950 . TL ؛ DR:

• نأمل أن تعمل React-Redux 5.1 مع <StrictMode> بدون تحذيرات (العلاقات العامة الحالية: https://github.com/reduxjs/react-redux/pull/980)
• 6.0 ستكون إعادة كتابة داخلية لاستخدام واجهة برمجة تطبيقات السياق الجديدة ، وإضافة إعادة توجيه المرجع ، وربما تغييرات أخرى ، ولكن حاول الاحتفاظ بأكبر قدر ممكن من واجهة برمجة التطبيقات العامة الحالية (على سبيل المثال ، <Provider> و connect() ). سنرى كيف يعمل ذلك بشكل جيد مع العرض غير المتزامن ، ونكتشف أفضل مسار للمضي قدمًا. (العلاقات العامة السابقة لإثبات المفهوم موجودة على https://github.com/reactjs/react-redux/pull/898 ، لكن من المحتمل أن نعيدها بناءً على الدروس الأخرى المستفادة من عمل 5.1.) سيتطلب هذا الإصدار React 16.5 كحد أدنى ، نظرًا للحاجة إلى سياق جديد وربما أيضًا "سياق القراءة من طرق دورة الحياة" الذي لم يتم إصداره بعد والذي تم دمجه للتو.
• بعد ذلك ، نحن منفتحون على الأفكار الخاصة بواجهة برمجة تطبيقات مختلفة لـ React-Redux (نعم ، نعم ، ربما يتضمن ذلك دعائم تصيير ، أشخاص).

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

نتطلع إلى إصدار Async التقديم والتشويق

acdlite استفسر أيضًا عن التشويق
سؤالي هو بمجرد تقديمها ويبدأ المرء في كتابة التطبيقات بهذا الإصدار الجديد من التفاعل: هل يعني ذلك أن تفاعل API والطريقة التي يتفاعل بها الأشخاص في التفاعل ستتغير أيضًا؟ (حتى لو لم يخططوا لاستخدام ميزات التشويق والعرض غير المتزامن؟)

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

أفترض أنه قد يكون من الأصعب كتابة كود رد الفعل مع التشويق

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

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

بطريقة ما أقول إذا كانت 10٪ من التطبيقات تحتاج إلى ميزة التشويق والعرض غير المتزامن ، فلماذا في 90٪ أخرى تجبر الناس على تعلم رد فعل "جديد"؟ لكن مرة أخرى قد أكون مخطئًا ، لأنني لم أجمع الكثير من المعلومات حول الشك والعرض غير المتزامن حتى الآن.

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

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

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

أنا حقا أنصح بمشاهدة حديثي . أنا متأكد من أن هذا سيكون أكثر منطقية بمجرد رؤية هذه الميزات قيد التشغيل.

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

جميع الأنماط القديمة تستمر في العمل.

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

حظا سعيدا.

مرحبًا دان (gaearon) ، أنا لا أتعامل مع الأمر ولكني أريد معرفة ذلك. أعلاه قلت:

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

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

ومع ذلك ، هنا ، يقول bvaughn أنه يمكن استدعاء getDerivedStateFromProps (أو componentWillReceiveProps) عدة مرات لتحديث واحد ، ومن ثم فإن حله هو عدم جلب البيانات بداخله.

إذن سؤالي هو ، بعد كل شيء ، أنه يبدو أننا لا نستطيع استخدام React الجديدة بنفس الطريقة تمامًا كما كان من قبل ، أليس كذلك؟ لأن AFAIK في مكون التفاعل الحاليWillReceiveProps لا يتم استدعاؤه عدة مرات لتحديث واحد ، أليس كذلك؟

@ giorgi-m: نعم ، تتغير طرق دورة الحياة ، ولكن النقطة المهمة هي أن التشويق نفسه هو ميزة اختيارية. ستعمل جميع توابع تصيير React الحالية وسلوك تصيير React كما هو. ومع ذلك ، إذا قمت بالاشتراك عن طريق إضافة علامة <AsyncMode> إلى جزء من تطبيقك ، _ و_ تبدأ في استخدام نهج Suspense للإشارة إلى احتياجات البيانات غير المتزامنة ، فيمكنك الاستفادة منها. لا يحدث أي من ذلك إذا لم تقم بإضافة ذلك إلى قاعدة التعليمات البرمجية الخاصة بك.

يجب استخدام @ giorgi-m componentDidUpdate بدلاً من componentWillReceiveProps أو getDerivedStateFromProps .

markerikson لذا فأنت تقول إن ما قاله bvaughn هنا ، أنه يمكن استدعاء _getDerivedStateFromProps_ عدة مرات لتحديث واحد ، ليس بالضرورة أن يكون الأمر كذلك ، إذا لم أقم بتمكين <AsyncMode/> ؟
(آسف لطرح مثل هذه الأسئلة ، فقط كانوا ينبثقون لي من وقت لآخر ، ولم يعثروا على الموارد التي من شأنها أن تغطي الجميع).

ملاحظة. لم يذكر bvaughn أيضًا اختيارية ذلك في الخيط المرتبط ، وبالتالي أثار شكوكي.

هل يجب إضافة طريقة لإدراج التحديثات غير المتزامنة في قائمة الانتظار (على سبيل المثال deferSetState() لمكونات الفئة بدلاً من unstable_deferredUpdates() الخاصة بالعارض) إلى قائمة التحقق الأساسية؟

من وجهة نظري ، ستكون أي تحديثات للألياف في mode غير متزامنة ، مما يعني من الناحية النظرية أن deferSetState() سيكون غير ضروري. ومع ذلك ، يمزج العرض التوضيحي unstable-async/suspense بين تحديث متزامن وتحديث غير متزامن ولست متأكدًا من كيفية تحقيق ذلك في الوضع async (للمكونات "العامة").

إنه في قائمة التحقق لمظلة تقطيع الوقت.

وعد الدعم كنوع مكون

مرتبط بهذا ، عندما يكون لديك:

const PromiseType = new Promise(() => {})
class A extends Component {
    componentDidMount() {}
    componentDidUpdate() {}
    render() {
        return <div><PromiseType></PromiseType></div>
    }
}

هل هناك أي استدلالات حول موعد استدعاء دورات الحياة componentDidMount و componentDidUpdate .

1. عندما يتم حل جميع الأطفال (بما في ذلك الوعد) ، ما يعني في هذه الحالة أنه لن يتم الاتصال بهم نظرًا لأن الوعد لم يتم الوفاء به أبدًا؟
2. متى تم تسليم جميع الأطفال المضيفين المباشرين؟

thysultan : يتم componentDidMount و componentDidUpdate في مرحلة الالتزام ، عندما يتم عرض شجرة واجهة المستخدم بالكامل وتطبيقها على DOM.

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

(شخص ما لا تتردد في تصحيح لي إذا كانت افتراضاتي خاطئة هنا :))

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

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

هل هناك أي شيء يمكننا القيام به للمساعدة في إطلاق سراح هذا؟ :د

يمكنك التجميع من السيد إذا كنت تريد اللعب. انظر التعليمات في fixtures/unstable-async/suspense

gaearon هل أنا محق في أن هذا في جانب العميل في حالته الحالية فقط (لذا يتعين القيام بالمزيد من العمل لدعم العرض من جانب الخادم)؟

EDIT ، وجد الإجابة: لأي شخص آخر يبحث بشغف عن استخدام Suspense in SSR للتطبيقات العالمية. لقد وجدت هذا التعليق من دان والذي يتيح لنا معرفة أن هذا جانب العميل فقط في الوقت الحالي. ومع ذلك ، يشير هذا التعليق أيضًا إلى https://www.youtube.com/watch؟v=z-6JC0_cOns الذي يتحدث عن الآثار المحتملة لـ SSR.

نحن في الواقع نبدأ بعض الأعمال المتعلقة بقضية SSR قريبًا.

تخيل هذا السيناريو في تطبيق غير متزامن يعمل على جهاز محمول منخفض التكلفة:

1. يوجد إعلان خارجي يتم تحميله باستخدام كل وحدة المعالجة المركزية (😓)
2. ينقر المستخدم على ارتباط ويطلق جهاز التوجيه عرضًا جديدًا
3. React في الوضع غير المتزامن ، لذلك ينتظر حتى يمنحه Chrome / Safari الإذن باستخدام وحدة المعالجة المركزية ، لكن الإعلان يستمر في التحميل لمدة 3 ثوانٍ أخرى
4. يعتقد المستخدم أن التطبيق لا يعمل

يمكن تجنب هذه المشكلة باستخدام نفس الأسلوب <Placeholder> تمت مناقشته مع Suspense ، حيث يظهر القرص الدوار بعد ثانية واحدة على سبيل المثال.

هل تم النظر في هذا السيناريو؟ هل سيعمل <Placeholder> للتصيير غير المتزامن البطيء؟

luisherranz هناك آليتان لمنع ذلك:

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

2. لم يعد React يستخدم في الواقع requestIdleCallback لأن المتصفحات لم تعد قوية بما يكفي حول جدولة ذلك. قد يتغير نهج الجدولة الدقيق أيضًا بمرور الوقت ، ولكن هذا بالتأكيد شيء نهتم به.

شكرا جزيلا للإجابة السريعة دان.

1. لدى React موعد نهائي مرتبط بكل تحديث

مدهش. هل توجد بالفعل واجهة برمجة تطبيقات يمكننا اختبارها؟

1. لم تعد React تستخدم في الواقع requestIdleCallback بعد الآن لأن المتصفحات لم تعد قوية بما يكفي بشأن جدولتها.

هذا ما جربناه أيضًا. في بعض الأحيان في أحد التطبيقات المزدحمة مع الإعلانات الخارجية والتضمينات من twitter أو youtube ، قد يستغرق الأمر عدة ثوانٍ حتى يتم استدعاء requestIdleCallback وينتهي العرض. لذا 👍 لذلك.

راجع للشغل ، بالنسبة لنا ، هناك حالة استخدام أخرى تتعلق بإجابتك الأولى: نحن نحاول استخدام lazyloads مع إزاحتين. الأول يؤدي إلى تشغيل عرض غير متزامن ، بينما يقوم الثاني بتشغيل عرض مزامنة إذا لم ينته عدم التزامن. شيء من هذا القبيل:

1. يقوم المستخدم بالتمرير لأسفل ويكون 1200 بكسل من عنصر ثقيل: على سبيل المثال المنشور التالي للمدونة.
2. الإزاحة الأولى تؤدي إلى عرض غير متزامن للمشاركة التالية.
3. يستمر المستخدم في التمرير لأسفل ويكون عند 600 بكسل في المنشور التالي.
4. مشغلات الإزاحة الثانية: إذا انتهت عملية النشر غير المتزامن (يُطلق على componentDidMount) ، فلن يحدث شيء ، ولكن إذا لم يحدث ذلك ، فسيؤدي ذلك إلى تشغيل عرض مزامنة للمنشور بأكمله.

لذا بدلاً من الوقت ، نود التحكم في التدفق بمشغل ثانٍ. هل له معنى؟ يمكن أن يكون من الممكن؟

هل توجد بالفعل واجهة برمجة تطبيقات يمكننا اختبارها؟

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

لذا بدلاً من الوقت ، نود التحكم في التدفق بمشغل ثانٍ. هل له معنى؟ يمكن أن يكون من الممكن؟

نعم هذا ممكن. لقد وصفت آلية مثل هذه هنا: https://github.com/oliviertassinari/react-swipeable-views/issues/453#issuecomment -417939459.

لست متأكدًا مما إذا كنت تقصد كلمة رئيسية أم لا (الوضع غير المتزامن غير متاح رسميًا في إصدارات npm)

نعم ، نحن نستخدم حزمة npm مع <unstable_AsyncMode> ، flushSync و unstable_deferredUpdates .

من فضلك ، ابدأ في إصدار إصدارات ألفا / بيتا بهذه التغييرات على npm! 🙏

نعم هذا ممكن. لقد وصفت آلية مثل هذه هنا: oliviertassinari / response-swipeable-views # 453 (تعليق).

متألق. أفضل بكثير من تطبيقنا الحالي باستخدام unstable_deferredUpdates :)

لا يمكنني الانتظار لبدء استخدام <div hidden> . أنتم يا رفاق تقومون بعمل رائع.

luisherranz كن حذرا ، هذه الأشياء _are_ غير مستقرة. قد يكون بها أخطاء أو تكون غير فعالة إلى حد ما (على سبيل المثال ، لم يتم تنفيذ التحسين الحاسم - "الاستئناف" - بعد). نحن نزيل unstable_deferredUpdates أيضًا لصالح الوحدة الجديدة schedule ( schedule.unstable_scheduleWork ).

نعم ، نحن نستخدمه فقط لجزء صغير من التطبيق ونختبره بشكل مكثف ولكنه جيد حتى الآن :)

قد يكون خارج الموضوع:
يتم استدعاء requestIdleCallback 20 مرة فقط في الثانية - Chrome على جهاز Linux 6x2 الأساسي الخاص بي ، إنه ليس مفيدًا حقًا لعمل واجهة المستخدم.
يتم استدعاء requestAnimationFrame كثير من الأحيان ، ولكنه مخصص للمهمة التي يقترحها الاسم.

لقد توقفنا عن استخدام requestIdleCallback لهذا السبب.

ما الذي تستخدمونه بدلاً من requestIdleCallback ؟

TejasQ https://github.com/facebook/react/tree/master/packages/scheduler

آه ، بالطبع. ما أغباني. كنت أتساءل عن واجهة برمجة تطبيقات المتصفح التي تستخدمها وحدة الجدولة بدلاً من requestIdleCallback . كان يجب أن أطرح السؤال بشكل أكثر وضوحًا. 😅

أوه ، واو ، وجدتها.
https://github.com/facebook/react/blob/eeb817785c771362416fd87ea7d2a1a32dde9842/packages/scheduler/src/Scheduler.js#L212 -L222

هذا رائع من المستوى التالي.

مرحبا،

أثناء محاولتي فهم التشويق ، أدركت أنه ليس لدي أي فكرة عن أي جزء من التطبيق يتم "تعليقه" فعليًا عند استخدام المكون Suspend 😳😱.

في المثال التالي أتوقع ظهور Title على الفور ، و Spinner بعد 1000 مللي ثانية و UserData بعد 2000 مللي ثانية (حيث يستغرق "تحميل" البيانات لهذا المكون 2000 مللي ثانية).
ولكن ما أراه هو أن Title يظهر لأول مرة مع Spinner بعد 1000 مللي ثانية.

// longRunningOperation returns a promise that resolves after 2000ms
const UserResource = createResource(longRunningOperation);

function UserData() {
  const userData = UserResource.read(cache, "Lorem Ipsum");
  return <p>User Data: {userData}</p>;
}

function Spinner() {
  return <h1>Fallback Loading Spinner</h1>;
}

function Title() {
  return <h1>Hello World</h1>;
}

function App() {
  return (
    <React.Fragment>
      <Title />
      <Suspense maxDuration={1000} fallback={<Spinner />}>
        <UserData />
      </Suspense>
    </React.Fragment>
  );
}

unstable_createRoot(document.getElementById("mount")).render(<App />);

(يمكنك العثور على المثال الكامل الذي يستخدم React 16.6.0-alpha.8af6728 هنا على codeandbox )

هل هناك طريقة لجعل Title مرئيًا على الفور و "تعليق" الجزء الآخر فقط من التطبيق؟ أم أنني أسأت فهم ربما التشويق بشكل كامل؟ (إذا كانت هناك طريقة أفضل لطرح هذا النوع من الأسئلة ، فيرجى إبلاغي بذلك)

شكرا!

مرحباnilshartmann! سؤال رائع!

هل هناك طريقة لجعل العنوان مرئيًا على الفور و "تعليق" الجزء الآخر فقط من التطبيق؟

إذا فهمت بشكل صحيح ، فستحتاج إلى إخبار React صراحةً بـ _لا تنتظر_ قبل مسح Title إلى DOM كما في هذا المثال لجعل Title مرئيًا على الفور و "تعليق" الآخر فقط جزء من التطبيق عن طريق تغليف الأجزاء التي تتوقع أن يتم تقديمها على الفور <Suspense maxDuration={0}> .

أتخيل أن هذا هو الحال بسبب بعض ميكانيكا الجدولة ذات المستوى الأدنى؟ أود أيضًا أن أفهم هذا بشكل أفضل ، لكن هذا من شأنه أن يحل مشكلتك في الوقت الحالي.

أنا متحمس لسماع ما يحدث بالفعل هناك.

(إذا كانت هناك طريقة أفضل لطرح هذا النوع من الأسئلة ، فيرجى إبلاغي بذلك)

لست متأكدًا من وجودها. 😄 يبدو الأمر واضحًا تمامًا بالنسبة لي. شكرا على السؤال!

TejasQ في متصفحي ، يؤدي تحميل المثال الخاص بك إلى عرض العنصر الدوار الاحتياطي على الفور. ألا يجب أن يتم التحميل بعد 1000 مللي ثانية؟

TejasQ شكرا لإجابتك ، ولكن karlhorky على حق: الآن الدوار يظهر على الفور.

ييكيس! فاتني ذلك. حاولت. 😅 اسمحوا لي أن ألقي نظرة أخرى عليها وأعود إليك. يجب ان اكون غفلت عن شيء ما. 🤷‍♂️

تحديث: أحاول اكتشاف ذلك هنا ويمكننا التعاون إذا كان أي شخص مهتمًا بالقيام بذلك معًا في الوقت الفعلي.

التحديث الثاني: لقد نظرت إلى @ philipp-spiess وأنا في حيرة من أمري. ما زلت لا أفهم ذلك. في هذه المرحلة ، لست متأكدًا مما إذا كان هذا خطأ لأن هذا ، في الواقع ، ميزة unstable_ وميزة alpha ، أو ما إذا كان شيئًا لا أراه ببساطة.

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

دعونا نرى ما سيقولونه. 😄 شكرًا لتوضيح ذلك ،nilshartmann!

هل تم إصدار هذا كجزء من React v16.6؟ في بلوق وظيفة يظهر المثال التعليمات البرمجية باستخدام المعلق:

import React, {lazy, Suspense} from 'react';
const OtherComponent = lazy(() => import('./OtherComponent'));

function MyComponent() (
  <Suspense fallback={<div>Loading...</div>}>
    <OtherComponent />
  </Suspense>
);

هل تم إصدار هذا كجزء من React v16.6؟

فقط حالة استخدام التحميل البطيء ، وفقط في وضع المزامنة. الوضع المتزامن لا يزال العمل قيد التقدم.

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

في المثال التالي ، أتوقع أن يكون العنوان مرئيًا على الفور ، و Spinner بعد 1000 مللي ثانية و UserData بعد 2000 مللي ثانية (حيث يستغرق "تحميل" بيانات هذا المكون 2000 مللي ثانية).

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

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

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

لقد فوجئت بمكتبة React Cache. بالنسبة إلى React Async ، لم أقم عن عمد بتضمين آلية ذاكرة التخزين المؤقت ولكني اخترت التعامل مع وعود الفانيليا. إضافة التخزين المؤقت فوق ذلك أمر سهل إلى حد ما.

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

مرحبا. كيف يمكنني اختبار الكود مع Suspense / Lazy؟
الآن Renderer.create (...) toTree () رميات
"toTree () لا يعرف حتى الآن كيفية التعامل مع العقد ذات العلامة = 13"

لماذا يتم استخدام العناصر maxDuration في Suspense فقط في Concurrent Mode بدلاً من وضع المزامنة والمتزامن. يمكن لأي شخص أن يساعد في شرح؟

(في الوقت الحالي) هذا يعني المدة التي يُسمح فيها لـ Concurrent Mode بترك هذه الشجرة معلقة قبل إجبارها على الالتزام - فهي تتحكم بشكل فعال في الموعد النهائي لتقسيم الوقت ، ولا يوجد تقسيم للوقت في وضع المزامنة. الانتظار قبل تنفيذ الشجرة سيؤدي بالضرورة إلى الالتزام ... وليس المزامنة.

لقد كنت أستخدم Suspense في تطبيق داخلي لجلب البيانات وسرعان ما تعرفت على سبب عدم استخدامها في جلب البيانات حتى الآن.

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

على سبيل المثال ، هناك خطاف فظيع حقًا من طلبي.

function useComponentList(id) {
  const incomingComponents = useSuspenseFetch(
    React.useCallback(() => getComponentAPI().listComponents(id), [id])
  )

  const map = React.useMemo(
    () =>
      Map(
        (incomingComponents || []).map(component => [component.id, component])
      ),
    [incomingComponents]
  )

  return useCacheValue(map)
}

هذا الخطاف:

1. يجلب البيانات باستخدام رد الاتصال المحدد من نقطة النهاية المحددة
2. يحول تلك البيانات إلى خريطة ImmutableJS - نظرًا لأن هذا قد يكون مكلفًا ، فأنا أحفظ العملية.
3. إرجاع الخريطة التي تم تغليفها في useCacheValue ، وهو الجزء غير المناسب بشكل خاص.

useCacheValue كالتالي:

export default function useCacheValue(value) {
  const [state, setState] = React.useState(value)
  React.useEffect(() => {
    setState(value)
  }, [value])

  return [state, setState]
}

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

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

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

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

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

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

gaearon عندما تقول "نحن نعمل على هذه الأشياء" ، هل هناك مشكلة يمكنني الاشتراك فيها أم أن هذه المناقشات تجري على انفراد؟

شكرا ، جايرون :)

ntucker كما هو الحال دائمًا ، يمكنك مشاهدة النشاط المستمر مثل العلاقات العامة. على سبيل المثال: https://github.com/facebook/react/pull/14717 ، https://github.com/facebook/react/pull/14884 ، https://github.com/facebook/react/pull/15061 ، https://github.com/facebook/react/pull/15151 ، https://github.com/facebook/react/pull/15272 ، https://github.com/facebook/react/pull/15358 ، https : //github.com/facebook/react/pull/15367 ، وهكذا. نحاول وضع بعض المعلومات الوصفية في كل علاقات عامة ، ويمكنك رؤية التغييرات السلوكية من الاختبارات. شريط التوثيق للتجارب منخفض لعدة أسباب.

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

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

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

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

أشارت خارطة الطريق التي تم الإعلان عنها في تشرين الثاني (نوفمبر) الماضي (https://reactjs.org/blog/2018/11/27/react-16-roadmap.html) إلى أن الإصدار "المتزامن" من Suspense كان مقررًا للربع الثاني من عام 2019. نحن الآن في Q3 2019. هل هناك تحديث يمكننا الحصول عليه بالتأكيد ليس Q3 ، أو ربما Q3 ، وما إلى ذلك؟

كان هذا آخر تحديث لخريطة الطريق وجدته: https://reactjs.org/blog/2019/08/08/react-v16.9.0.html#an -update-to-the-roadmap

قدمنا ​​إصدارًا تجريبيًا مرة أخرى في أكتوبر: https://reactjs.org/docs/concurrent-mode-intro.html. هذا هو نفس البناء الذي نديره في الإنتاج. لا يزال هناك المزيد من العمل الذي يتعين القيام به (سواء من حيث تعديل واجهة برمجة التطبيقات وإنشاء واجهات برمجة تطبيقات ذات مستوى أعلى) ولكن يمكنك البدء في اللعب بها إذا كنت تريد ذلك.

التشويق يقتلني

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

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

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

هذا مشروع متعدد السنوات. الجواب الصادق هو أنه أنتج المزيد من العمل أكثر مما كنا نظن عندما بدأناه قبل عامين.

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

إليك حالة تقريبية لمسارات العمل المختلفة اليوم:

• <Suspense> API لتقسيم الشفرة باستخدام lazy . (تم شحنها في React 16.6)
  
  
  
  • كما تعلم ، يمكنك استخدام هذا بالفعل.
  
  
• واجهات برمجة تطبيقات الوضع المتزامن ، على سبيل المثال createRoot و useTransition . ( متوفر في إصدارات experimental )
  
  
  
  • حل التوافق للمكتبات مثل Flux. ( قيد التقدم bvaughn ، https://github.com/reactjs/rfcs/pull/147)
  
  
  • تغيير نموذج الأولوية إلى نموذج أكثر عقلانية. ( قيد التقدم acdlite ، https://github.com/facebook/react/pull/18612)
  
  
  • السماح فقط بالانتهاء من آخر انتقال معلق. ( قيد التقدم acdlite)
  
  
  • Offscreen API ( قيد التقدم lunaruan)
  
  
  • تأثيرات النار عند إخفاء / إظهار محتوى للتشويق
  
  
  • تأثيرات النار عند إخفاء / إظهار المحتوى لبرنامج Offscreen
  
  
  • إظهار وإخفاء أطفال البوابة عند الحاجة
  
  
  • التوافق مع أعمال التقييس الجارية للجدولة ( لم تبدأ )
  
  
  • إصلاح الأخطاء الرئيسية المعروفة ( قيد التقدم gaearon وacdlite)
  
  
  • تغيير دلالات الحدث. (في التقدمtrueadmsebmarkbage)
  
  
  • تفويض إلى الجذور بدلاً من المستند لتمكين المزيد من التبني التدريجي ( قيد التقدم ،trueadm)
  
  
  • تدفق الأحداث المنفصلة في مرحلة الالتقاط.
  
  
  • ضع في اعتبارك الحصول على أولوية افتراضية من event للعب بشكل أفضل مع التعليمات البرمجية الضرورية.
  
  
  • إنهاء دلالات API وافتراضيات أخرى. ( لم تبدأ )
  
  
  • تحديث الكتابة والوثائق.
  
  
• التشويق لجلب البيانات
  
  
  
  • دعم منخفض المستوى للإشارة إلى أحد المكونات غير جاهز للعرض ( متوفر تقنيًا في React المستقر أيضًا ، لكن واجهة برمجة التطبيقات هذه لا تعتبر مستقرة).
  
  
  • يقوم عارض الخادم بمسح احتياطي التعليق فورًا ( متوفر في الإصدارات التجريبية)
  
  
  • حل لحالات استخدام GraphQL (خطافات الترحيل ، مشحونة ).
  
  
  • حل لحالات استخدام بخلاف GraphQL ( قيد التقدم sebmarkbage بالتعاون مع Next.js).
  
  
  • تكامل الحزم للاعتماديات التي تعتمد على البيانات. ( قيد التقدم )
  
  
  • إنهاء Blocks API ، بما في ذلك السياق.
  
  
  • حل عام للتخزين المؤقت. ( لم تبدأ )
  
  
  • نوع من تكامل جهاز التوجيه.
  
  

يبدو الأمر كأنه "قيد الإنتاج في Facebook ، لذلك انتهينا".

أستطيع أن أرى كيف يمكن أن تبدو بهذه الطريقة ، على الرغم من أن هذه القراءة محبطة بعض الشيء. :-) لقد عملنا بلا توقف على هذا طوال الأشهر الماضية ، والعديد من الجوانب الفنية إما أنتهت أو شارفت على الانتهاء. تنقسم معظم الأعمال المتبقية إلى فئتين:

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

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

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

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

لتلخيص ذلك: هناك المزيد من العمل الذي يتعين القيام به.

gaearon شكرا لك على هذا التحديث! وأنا أعتذر إذا كانت نبرتي خاطئة. أعترف أنني كنت محبطًا بعض الشيء وأنا أجوب موقع تويتر لأشهر ولم أجد شيئًا. يبدو هذا الجانب Server renderer immediately flushes Suspense fallbacks (available in experimental releases) شيئًا يمكنني تخصيص وقت له في اختبار هذا باستخدام Apollo Graphql لتنفيذنا.

نعم ، يجب أن يكون جاهزًا لمؤلفي المكتبات والأشخاص الفضوليين لبدء اللعب معهم. تتعلق الأجزاء المفقودة في الغالب بتوفير "مسارات سعيدة" ولكن يجب أن تكون معظم أعمال السباكة موجودة.

يقوم عارض الخادم بمسح احتياطي التعليق فورًا (متوفر في الإصدارات التجريبية)

أين يمكنني أن أقرأ عن هذا؟ كنت أتمنى أن يكون مرجع واجهة برمجة تطبيقات الوضع المتزامن (تجريبي) ولكن لم يحالفني الحظ.

إذا كان لدى أي شخص عرض توضيحي لـ Next.js و Relay Hooks و Concurrent Mode معًا (مع SSR) فسيكون ذلك رائعًا. وإلا فقد أجرب حظي إذا تمكنت من العثور على وثائق كافية.

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

لا توجد مستندات إضافية حول SSR ولكنها في الغالب لأنها مجرد سلوك افتراضي جديد.

إذا كان لديك إصدار تجريبي أكثر من أي وقت يتم فيه تعليق أحد المكونات على الخادم ، فإننا نقوم بمسح أقرب عنصر احتياطي للتعليق بدلاً من ذلك. ثم على العميل ، ستستخدم createRoot(node, { hydrate: true }).render(<App />) .

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

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

ربما يمكنك أن تسأل devknoll عن محاولات / أمثلة التكامل التالية. ربما لديه بعض.

يمكنك تمكين الوضع المتزامن في Next.js عن طريق تثبيت react@experimental و react-dom@experimental وإضافة التالي إلى next.config.js

// next.config.js
module.exports = {
  experimental: {
    reactMode: 'concurrent'
  }
}

إليك مناقشة Next.js حول هذا: https://github.com/zeit/next.js/discussions/10645

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

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

gaearon هل تقصد أنه يمكنك عرض مكون بشكل طبيعي على الخادم ، ولكن استخدام React.lazy على العميل؟ مما يسمح لك بإرجاع العلامة الكاملة من الخادم ، ولكن يؤخر تحليل كود المكون وعرضه على العميل. الخادم المقدم يعمل الترميز باعتباره احتياطي التشويق هنا؟

robrichard لم React.lazy وجه التحديد (نستخدم غلافًا مختلفًا في FB ولديك Next أيضًا نسخته الخاصة) لكنني أتوقع أن هذه هي الطريقة التي ستعمل بها. يستحق التحقق :-) مع بعض القيود - على سبيل المثال ، إذا قمت بتحديث الدعائم ولم تكن هناك مذكرة إنقاذ أعلاه ، أو إذا قمت بتحديث السياق أعلاه ، فسيتعين علينا إزالته وإظهار الرجوع لأننا لا نعرف ما يجب القيام به معها.

gaearon ما هو الوضع الحالي

لقد تم تشغيله في كل إصدار @experimental لفترة طويلة حتى الآن ، طالما أنك تستخدم unstable_createRoot API.

إليك عرض توضيحي: https://codesandbox.io/s/floral-worker-xwbwv؟file=/src/index.js

gaearon هل أنت قادر على إرضاء ما تعنيه بعبارة "التبعيات المدفوعة بالبيانات"؟

gaearon هل أنت قادر على إرضاء ما تعنيه بعبارة "التبعيات المدفوعة بالبيانات"؟

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

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

لدينا معايير عالية جدًا لما يدخل في رد الفعل "الرسمي". لكي تكون "Reacty" ، يجب أن تؤلف كما تفعل مكونات React العادية. هذا يعني أنه لا يمكننا أن نوصي بحسن نية بحل لا نعتقد أنه سيشمل آلاف المكونات. لا يمكننا أيضًا التوصية بحل يجبرك على كتابة التعليمات البرمجية بطريقة معقدة ومحسّنة للحفاظ على أدائها. في FB ، تعلمنا الكثير من الدروس من فريق Relay. نعلم أنه لا يمكن للجميع استخدام GraphQL ، أو قد يرغبون في استخدام Relay (فهي ليست شائعة جدًا في حد ذاتها ولم يقم الفريق بتحسينها للتبني الخارجي). لكننا نريد التأكد من أن حل جلب البيانات الخاص بنا لـ React العامة يشتمل على الدروس المكتسبة بشق الأنفس من Relay ولا يعاني من الاضطرار إلى الاختيار بين الأداء والموقع المشترك.

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

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

الآن ، مرة أخرى ، نحن لا نضع Relay في React ، ولا نريد إجبار الأشخاص على استخدام GraphQL. ولكن من الناحية المفاهيمية ، فإن الميزة نفسها عامة ، ووجود حل جيد مفتوح المصدر لها من شأنه أن يتيح للأشخاص القيام بالكثير من تقسيم الكود أكثر مما يحدث اليوم (وبالتالي شحن كود JS للعميل أقل بكثير!) لن يتم استدعاء هذه الميزة العامة "التبعيات المدفوعة بالبيانات" - هذا مجرد اسم ترحيل أشرت إليه. ستكون هذه الميزة جزءًا من حل موصى به أكبر لا يتطلب GraphQL. لقد أشرت إليه للتو بهذا الاسم في القائمة لأن هذا كان كثيرًا لشرح نقطة قائمة واحدة.

آمل أن يوضح هذا الأمر.