React-native-router-flux: لماذا يوجد الإصدار 4 إذا كان يعتمد على تفاعل التنقل؟

سؤال جيد. سأقوم بتقديم Lighting Talk عنها لـ ReactiveConf:
https://blog.reactiveconf.com/open-call-for-reactiveconf-lightning-talks-2017-a4f5394e5f96

سوف تنشر قريبا.

اقتراح حديثي
https://gist.github.com/aksonov/e2d7454421e44b1c4c72214d14053410

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

أرى React Native Router كغلاف فوق React Navigation API مما يجعله أسهل في الاستخدام ودعمًا أفضل.

@ Maxwell2022 هذا من

1. رد فعل تدفق جهاز التوجيه الأصلي (RNRF) هو أكثر نضجًا وأقل عربات التي تجرها الدواب (فقط 7 من 1600 مشكلة مفتوحة ، مقابل رد الفعل الذي يحتوي على 75 ٪ من ~ 1000 مشكلة لا تزال مفتوحة (لا يستحق الإنتاج ، وغير مقبول في رأيي) )

2. إذا كنت مجرد مبرمج ، فإن رد الفعل يعد خيارًا رائعًا ، ولكن إذا كنت مبرمجًا ورجل أعمال في حاجة إلى الكفاءات ، فإن رد الفعل يعد خيارًا سيئًا (إليكم السبب: إن الملاحة أكثر تعقيدًا مما يجب أن تكون عليه ، و لديه منحنى تعليمي أطول بكثير ، خاصةً عندما يكون للتطبيق الخاص بك متطلبات تنقل معقدة وعدم كفاية وثائق lib تتركك تجرِّب دون داعٍ لساعات (أتفق مع هذا أمر رائع للمبرمج الذي يبحث عن تحدٍ ويريد تحسينه مهارات استكشاف الأخطاء وإصلاحها ، ولكنها غير مقبولة لمتاجر التطوير أو رجال الأعمال حيث يلزم توفير الوقت )

3. رد الفعل ، في جوهره ، لديه واجهة برمجة تطبيقات لطيفة ، لكنه معقد بلا داعٍ (أتفق مع AlmogRnD ) ... الغرض من هذا RNRF lib وما يفعله aksonov مع

4. إذا كنت من محبي عرض المكون / الشاشة الشرطي ، وهو نمط شائع جدًا في React Native ، فإن RNRF أكثر ملاءمة لهذا النمط

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

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

https://github.com/react-community/react-navigation/issues/2031

لم يكن ذلك من أجلي فقط بل للجميع. يجب إضافة هذا في README.

هل سيكون من المنطقي تركيز الجهود على تحسين التنقل في ردود الفعل (الأساسية أو التوثيق)؟

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

@ Maxwell2022 تحسين رد الفعل بدلاً من ذلك؟ ربما كنت تمزح ، حقا. للتجربة فقط ، قدمت علاقات عامة مفيدة حقًا https://github.com/react-community/react-navigation/pull/1999 ، استغرق الأمر أسبوعين (!) لإكمال المراجعة ، وقمت بإصلاح جميع الاقتراحات (!) من المراجعين وبعد ذلك قال ذلك أحد المؤلفين إن علاقاتي العامة ليست ضرورية لأنه عمل على "إعادة هيكلة" واجهة برمجة تطبيقات navbar! حسنًا ، ربما تغيرات جديدة مفاجئة ... وتحقق من العلاقات العامة الأخرى ، لم يتم دمج الكثير من العلاقات العامة المفيدة جدًا لشهور.

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

aksonov إذا كان من الصعب تحسين ReactNavigation (بسبب بطء دمج العلاقات العامة وكلها) ، ألا يمثل ذلك مشكلة بالنسبة للإصدار 4؟

يمكن حل العديد من المشكلات مثل تخصيص شريط التنقل (مثل تعيين صور شريط التنقل الأيمن / الأيسر) ، ومعالجة الإجراءات (مثل إضافة popTo المفقودة) بواسطة RNRF.
ولكن بالنسبة لبعض المشاكل مثل # 2012 ، نعم ، علينا انتظار الإصلاح. يمكننا أن نفترق ReactNavigation ونطبق علاقات عامة مقترحة في المستقبل (صحيح ، العديد من العلاقات العامة تحل المشاكل ولكن لم يتم دمجها بعد).

على أي حال ، يعتمد الإصدار 3 على تنقل تجريبي-أصلي-تجريبي قديم ، لذلك لا أرى أي بديل أفضل.

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

هنا 2 سنتي.
لقد كنت أستخدم RNRF في أحد مشروعي لفترة طويلة ، وهذا ما واجهته:

• كان الانتقال مؤلمًا ، لقد مررت بالعديد من الانتقالات التي ستستغرق لحظة (حتى عدة ثوانٍ) قبل البدء بعد الضغط على زر. ولقد استخدمت بالتأكيد مدير التفاعل.
• كان من الصعب استخدام التسلسل الهرمي للتوجيه. غالبًا ما استغرقت ساعات قبل أن أضع الأمور في نصابها الصحيح وأكون قادرًا على الانتقال من مشهد إلى آخر
• ما زلت لا أفهم ما تعنيه بالفعل PUSH / PULL والأشياء الأخرى
• الوصول إلى التوجيه باعتباره تبعية ضمنية بدلاً من امتلاكه كدعائم أمر خاص بـ RNRF ومزعج إلى حد ما. يربط المشروع بإحكام بالملاحة.
• قد تقول أن المستند مروع بشأن ReactNavigation ، لكن مستند RNRF ليس ودودًا على الإطلاق. لم يساعدني المثال التفصيلي أبدًا ، ولا يخبرني المستند كثيرًا عن كيفية عمله. قد تكون وثائق ReactNavigation معطلة أو بعضها ، لكنني شخصياً لم أواجه أي مشكلة معها ، من خلال أنا محدث. حتى أنني بدأت في العمل على إعادة كتابة كاملة للمستند مرة واحدة ولكن لم يكن لدي الوقت الكافي لتخطيها. أعتقد أن مستند RNRF يتطلب إعادة كتابة كاملة للوثائق.

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

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

أتفق تمامًا مع Rewieer

بخصوص التحولات البطيئة:
Rewieer هل تقوم بتمرير الكثير من الدعائم أو تقوم بتحميل البيانات من الحالة عبر Redux أو شيء مشابه؟ هل تم اختبار ذلك أيضًا في أجهزة محاكاة iOS أو Android؟

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

عذرا للذهاب خارج الموضوع.

typeslower حتى الآن كان يعمل بشكل جيد على المحاكي ولكنه كان بطيئًا بشكل مؤلم على الهاتف.
أتذكر في ذلك الوقت أنني كنت أستخدم Immutable مع Redux لكن قاعدة الكيان لم تكن ثقيلة جدًا. كان لديّ Redux-Persist مع 200 مللي ثانية تنطيط أيضًا. لذلك ، ربما يؤدي تحميل البيانات من الحالة باستخدام غير قابل للتغيير مع أنواع ومرشحات إلى إبرام صفقة ، ولكن في قائمة <100 عنصر ، من الصعب التفكير في أن هذا يمكن أن يكون له هذا التأثير الهائل.
لم أجربه من قبل على IOS لأنني لا أمتلك أشياء من Apple على أي حال. تم اختبار هذا فقط في Android. لكنني أتذكر أن استخدام أدوات التنقل الأخرى كان جيدًا.

أود أن أقول آسف لأنني ما زلت في عكس V4 ، حيث أعتقد أن V3 لا يزال الأفضل.

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

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

على أي حال ، ما زلت داعمًا جدًا للإصدار الجديد ، لكنني الآن ألتزم بـ V3 بدلاً من ذلك. لأنني حقًا أحب هذا الاتساق بين الأجهزة المختلفة.

يتعلق الأمر حقًا بالسرعة التي تحتاجها لتسليم عملك. أعمل في بيئة وكالة تسويق وكان RNRF لا يقدر بثمن بالنسبة لنا. لم يكن هناك وقت لإتقان تعقيدات React Navigation ولذا قررنا المضي قدمًا مع RNRF منذ اليوم الأول. لقد عانيت قليلاً من التوثيق ، ولكن مع ذلك عملت في طريقي من خلاله وقمنا بتسليم التطبيقات الموجودة حاليًا يعمل بسرعة 60 إطارًا في الثانية على معظم الأجهزة.
مرة أخرى - عملي هو تسليم التطبيقات في تاريخ معين. لا يهمني ما إذا كانت RNRF تجريدًا لتقنيات أخرى. لا يهمني إذا كان أحد المشاريع يحتوي على 100 إصدار مفتوح والآخر 200. لا يهمني البتات والأجزاء الأساسية لـ RNRF. لقد حلت جميع مشاكلي وأنا سعيد بها بنسبة 100٪.

rodperottoni من فضلك أخبرنا المزيد عن نوع التعقيد الذي تتحدث عنه عندما تشير إلى React Navigation ، بدافع الفضول فقط.

تضمين التغريدة
ضع في اعتبارك أنني لست ضد React Navigation. السبب في استخدامي RNRF هو أنه يسمح لي بفعل الشيء نفسه ، ولكن بشكل أسرع. لا أعرف كيف أشرح ، لكن تجربة المطور ببساطة ... أفضل.

• بالنسبة لي ، من المنطقي أكثر أن أصرح عن مساراتي بصيغة JSX الخالصة ، مثلما تسمح لي RNRF بذلك. إنها ليست أبسط فحسب ، بل إنها أيضًا أنظف وأسهل في القراءة. الآن لا أقول إن JS يصعب قراءته (نظرًا لأن مسارات React Navigation معلن عنها بلغة js خالصة) ، ولكن في بعض الأحيان عندما يكون لدي مصمم أو مدير مشروع يراجع شيئًا معي ، يكون الأمر أسرع بالنسبة لي (وأقل مللاً بالنسبة لهم) ) للعثور على مسار وإجراء تغييرات عليه على الفور.
• أعتقد حقًا أن اصطلاحات التسمية الجيدة يمكن أن تجعل كل شيء أسهل. أنا شخصياً أحب اصطلاحات التسمية في RNRF أكثر من تلك المستخدمة في React Navigation.
• على الرغم من أن وثائق RNRF ليست "كاملة" مثل React Navigation ، إلا أنني ما زلت أحبها. صور GIF وأمثلة aksonov وضعتني منذ المرة الأولى التي كنت أدرس فيها هذا lib. تم تحديثها أيضًا مؤخرًا وهي أفضل بكثير من مستندات v3.
• أخيرًا وليس آخرًا ، تستغرق تجربة مكتبات جديدة وقتًا. يعمل RNRF بشكل لا تشوبه شائبة بالنسبة لي ، وبالتالي لا أرى قيمة في تجربة مكتبة توجيه أخرى دون سبب وجيه. ربما إذا واجهت مشكلة كبيرة ، فسأفكر في القفز إلى قارب آخر ، لكن في الوقت الحالي أنا سعيد جدًا بـ RNRF (شكرًاaksonov).

ملاحظة: تم إغلاق هذه المشكلة لأنها ظلت غير نشطة لأكثر من 30 يومًا.
يمكنك إعادة فتح هذه المشكلة إذا تم إغلاقها عن طريق الخطأ.