Redux: حان وقت الإحياء وذهب

https://github.com/rackt/redux/issues/464

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

يعد Redux بالطبع أكثر وضوحًا ولا يحل مشكلة جلب البيانات التعريفية لك. هناك محاولات لدمج Redux و GraphQL ولكن لا يمكنني تقييمها مقابل Relay - فأنا أعرف القليل جدًا عنها.

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

يُعد الجلب التصريحي لـ GraphQL أمرًا مذهلاً ومن الدرجة الأولى. ومع ذلك ، لا يزال Relay يحتوي على واجهة برمجة تطبيقات HoC بشكل أساسي ، وهي ليست تعريفية في حد ذاتها. إذا كان Relay سيوفر واجهة برمجة تطبيقات أكثر مرونة ، غير مفصولة عن شجرة المكونات ، فحينئذٍ يمكن كتابة ربط Redux مناسب؟

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

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

طريقة جيدة لوضعها؛ هذا ما أشعر به حيال ذلك أيضًا.

gaearon مواكبة العمل الجيد مع إعادة! واحدة من أفضل الأدوات الجارية! أنا أستخدمه في 5 تطبيقات كبيرة و 2 تطبيقات صغيرة في شركتي وأحبها!

gaearon مواكبة العمل الجيد مع إعادة! واحدة من أفضل الأدوات الجارية! أنا أستخدمه في 5 تطبيقات كبيرة و 2 تطبيقات صغيرة في شركتي وأحبها!

: 100:

أعتقد أنهم ليسوا نفس الشيء:

• الترحيل - لحل إدارة جلب البيانات من الخادم
• إعادة - لحل إدارة حالة التطبيق

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

السؤال هو كيف ترتبط Relay بأنماط التصميم المستوحاة من التدفق؟ أين تنتهي ريلاي ، متى نحتاج إلى إعادة؟ هل Relay Flux 2.0؟

مثال Todo Relay: هل يجعل الإعادة قديمة؟

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

بحاجة لمعرفة المزيد حول ما هو ريلاي. إنه ليس بضع مئات من الأسطر من التعليمات البرمجية وهذا أمر مؤكد!

oriSomething أنت لست على حق تماما. ريلاي يحل الكثير من إدارة الدولة أيضًا.

gyzerok لقد قصدت حالة التطبيق من جانب العميل

oriSomething نعم ، أنا أتحدث عن حالة التطبيق من جانب العميل

gyzerok لقد فاتني ذلك. هل يمكن أن تعطيني رابطًا حول هذا؟

oriSomething لا يوجد ارتباط خاص لأن Relay تديره بشكل ضمني. ربما يمكنك محاولة مشاهدة محادثات FB حول Relay. يتحدثون عن كيفية حل Relay لمشكلة ذاكرة التخزين المؤقت. ذاكرة التخزين المؤقت للتطبيق من جانب العميل = الحالة. أنا لا أتذكر الكلام المحدد ، آسف.

oriSomething يجب على مطور المكان الوحيد القيام ببعض إدارة الحالة الصريحة هنا .

gyzerok ، حسنًا ، في هذه الحالة ، هل هناك إدارة حالة غير مرتبطة بالخادم الذي يعمل الترحيل؟ بقدر ما أفهمه لا ، أم هو كذلك؟

oriSomething إذا فهمت أنك بشكل صحيح ،

oriSomething نعم ، يفعل => https://facebook.github.io/relay/img/Guides-Containers-HOC-Relay.png
تحقق: https://facebook.github.io/relay/docs/guides-ready-state.html#content

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

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

لذلك صنعت Slim-redux.js من أجل المتعة فقط - نسخة من Redux بدون تعليقات وتحذيرات للمطورين وفحوصات سلامة. يجتاز جميع اختبارات Redux الأساسية (باستثناء اختبارات التحقق من الصحة) ، وهو 99 سطرًا: wink:. هذا يجب أن يختم وجهة نظري بأن Relay و Redux هما أدوات ذات نطاقات مختلفة تمامًا.

IwanKaramazow أعتقد أنني لم أكن واضحًا بما فيه الكفاية ، ما أحاول قوله ، ليست كل البيانات تتعلق بالخادم ، هناك بيانات لا تتعلق بالخادم لإدارتها ، ولا أعتقد حقًا الترحيل هي "أداة" الانتقال حتى لو كانت قادرة على إدارة هذه البيانات

oriS شيء يمكنك إعطاء مثال؟

موافق تماما @ ماتابرسون . كل شيء ينزل إلى تعريف المعقد ، أو الأفضل ، حيث يتعرف كل فرد على "الشيء المعقد"

IwanKaramazow أعتقد أن oriSomething يتحدث عن حالة جانب العميل على سبيل المثال

انتقلت من Redux => Relay بسبب GraphQL. كانت جميع الموارد في طلبي في الغالب ذات تسلسل هرمي. من الطبيعي أن تكون كيانات متداخلة منطقية. كان الاحتفاظ بذاكرة تخزين مؤقت لهذه النماذج في Redux أمرًا مذهلاً. كان لدي عرض عاقل لبياناتي ويمكنني التكرار بسرعة باستخدام أدوات تطوير redux الرائعة.

ولكن بدون GraphQL ، كان علي القيام بالعديد من الرحلات ذهابًا وإيابًا لتعيين الموارد البعيدة إلى شجرة إعادة الإرسال.

1. / Resource1-list
2. / Resource2-list؟ Resource1 =
3. / Resource3-list؟ resources2 =

من الواضح أن هذه مشكلة في REST ، وليس Redux. لو رأيت بعض روابط Redux-GraphQL في وقت سابق ، فربما كنت سأستخدمها. تغير اعتماد الترحيل قليلاً جدًا في طلبي. بدلاً من @connect أنا أستخدم Relay.createContainer . كلا المنتجين لهما نفس الرؤية للهندسة المعمارية مع واجهات برمجة تطبيقات مختلفة. لقد كتبت منشورًا سريعًا على هذا.

أنا أستخدم حاليًا كلاً من redux و relay / graphql وعلى الرغم من أن الترحيل مذهل لجلب البيانات ، يمكنني أن أرى نفسي أستخدم redux دائمًا. أنا حاليًا أستخدم redux لسببين ويمكنني أن أرى نفسي أجد المزيد من الأسباب في المستقبل

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

أيضا ، redux devtools رائع.

يا رجل يا رجل. لقد كنت أقرأ على Relay اليوم ، ولا بد لي من الاعتراف بأن الكود ليس من السهل قراءته وليس من السهل فهمه. نظرت إلى بعض الأمثلة على Redux وتمكنت من فهم المفاهيم الأساسية بمجرد قراءة الكود.

يبدو البرنامج التعليمي أو مثال Todo غير أنيق. أعتقد أن React و FLUX يفخران بكونهما بسيطين. لا أشعر بهذا الشعور من Relay حتى الآن.

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

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

timdorr هل حاولت تخزين كل دولتك في Falcor؟ وجود مخفضات تستخدم كائن Falcor ، على سبيل المثال.

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

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

gaearon كيف React بجلب بيانات توضيحية بكتابة نفس التطبيق في Elm؟

يبدو لي أن الاختلاف الرئيسي هو أن جلب البيانات أكثر وضوحًا مع Relay & GraphQL (يطلب منك Elm تحديد عنوان URL ، والأمر متروك لك لفرز البيانات التي تعود) ، وكل شيء آخر أكثر وضوحًا في Elm .

في الواقع ، يبدو أن نظام Elm البيئي يمكن أن يستفيد من منفذ Relay / GraphQL.

فيما يتعلق بتجميع الاستعلام ، هناك طريقة Model.batch . يستغرق الأمر فترة زمنية (بالمللي ثانية) أو جدولة ، لكنني لا أجد الكثير من الوثائق حول المجدولين.

إذا كنت لا تمانع في أن أسأل ، كيف يتم دمج Redux و Falcor؟ كل محاولاتي تركتني محبطة.

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

لأي شخص يتساءل عن علاقة Redux مع Relay ، وما إذا كان من المنطقي استخدامهما معًا ، راجع: https://github.com/facebook/relay/issues/114

الجوهر هو أن Relay سيتعامل في النهاية مع البيانات من مصادر متعددة (الخلفية ، البيانات المؤقتة المحلية ، وما إلى ذلك) ، لذلك يحل محل تطبيقات Flux الأخرى التي قد تستخدمها.

https://github.com/facebook/relay/issues/168#issuecomment -135169255:

لاحظ أن Relay هو تنفيذ لنمط Flux (هل يمكن أن يحل Flux محل نفسه؟ ؛-).

نحن نستخدم كلاً من Redux و Relay بكثافة في OpenGov. صحيح أنه منذ الانتقال إلى Relay ، أصبح المجلد reducers/ أصغر كثيرًا. ومع ذلك ، وجدنا أن Redux لا يزال مفيدًا جدًا لإدارة الحالة المحلية على مستوى التطبيق. ربما يومًا ما ستحل محلها ريلاي في تلك المنطقة أيضًا. ولكن كما قال josephsavona ذات مرة ، فإن "بنية Redux" هي في الحقيقة مجرد وظائف ... :) حتى إذا انتقلت يومًا ما من مكتبة Redux ، فمن المحتمل أن تستمر في استخدام تحديثات الحالة الثابتة وتدفق البيانات التفاعلي والمخفض وظائف ، وما إلى ذلك في المستقبل المنظور. هذا هو الجزء القيم من Redux IMO ، وليس بالضرورة مكتبة <100-line الموجودة في هذا الريبو. (أوه ، والمجتمع ، بالطبع.)

أود أن أقول إذا كان تطبيقك مليئًا بالبيانات على غرار Facebook (العديد من الكيانات المتداخلة ذات العلاقات المعقدة) ، فمن الجيد الاستثمار في واجهة GraphQL الخلفية وتعلم Relay.

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

ما رأيكم يا رفاق في https://github.com/gyzerok/adrenaline؟

ليس مناسبًا تمامًا ، لأنه لا يستخدم Relay ، ولكن ما رأيك في هذا النهج الكامل المكدس خارج مجتمع Meteor؟ https://github.com/mattkrick/meatier

يمكن فقط للهندسة المعمارية العميقة مثل GraphQL / Relay أو Datomic / Om.Next حل مشكلة مقاومة الكائن / العلائقية ... ها هي أفكاري - نقدر التعليقات.

GraphQL / Relay: نهاية الإحياء؟

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

من الغريب ما يعتقده الناس حول هذه المجموعة من مبادئ التصميم: https://github.com/apollostack/apollo-client/pull/7/files؟

مجرد إضافة 2cents الخاصة بي هنا: لا أعتقد أن هناك نهاية لـ Redux. إنها بسيطة وجميلة وكافية في كثير من الحالات. إن نظام JS البيئي سريع جدًا ويصعب مواكبة ذلك ، و Redux ، مثل React بطريقة ما ، هو علامة فارقة يمكننا الاعتماد عليها لبعض الوقت. لا يمكننا تطوير سير العمل لدينا كل شهر (أو على الأقل ، لا يمكنني ذلك) ، وأعتقد أن Redux خيار جيد حقًا في الوقت الحالي. الترحيل (وجلب البيانات بشكل عام) ليس مطلوبًا في العديد من المشاريع ...

gaearon مرت بضعة أشهر منذ أن المنشور ، وقد

likeabbas إذا كنت تبحث عن تكامل GraphQL-Redux ، فجرب عميل Apollo: http://docs.apollostack.com/apollo-client/index.html

ليس لدينا ميزة تكافؤ بنسبة 100٪ مع Relay حتى الآن ، لكننا نقترب.

gaearon لتردد السؤال من likeabbas : "أين تقول أننا الآن من حيث تكامل GraphQL مع Redux مقارنةً بـ Relay / ، أو ربما مزيج من الثلاثة؟"

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

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

josephsavona : هذا ملخص _great_ ل Redux! قد نضطر إلى سرقة ذلك للمستندات في مكان ما :)

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

>.> lock the issue

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

عذرًا ، الزر الخطأ. آسف لذلك 😄