<p>dva 2.0</p>

ماذا عن دعم السكان الأصليين للملاحظة؟

عند إلغاء التصميم ، هل تفكر في دعم تمرير مخفض لتدمير بيانات الحالة غير المستخدمة؟ https://github.com/dvajs/dva/issues/769

ماذا عن dva-cli إعادة تسميته إلى roadhog؟ لئلا يتم الخلط بين المفهوم.

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

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

nihgwu كنت مخطئًا ، بمعنى أنه ، مثل antd ، مكتوب في ts ولا يقيد المستخدمين. وهذا له ميزة عدم الاضطرار إلى مزامنة ملفات الكتابة ونشرها يدويًا طوال الوقت.

أوافق على حل المكون الإضافي ، هل من الممكن القيام بذلك:

view - dva-core - [插件]

من بينها ، الجزء الذي يساوي dva الحالي هو:

• dva النواة
• dva- ملحمة
• جهاز التوجيه

آخر اثنين من المكونات الإضافية.

هل يمكن وضع dva كمكتبة تركز على التعبير عن العلاقة بين المشاهدات والبيانات؟ ما هو نوع إطار العمل هو طريقة العرض ، وما هي الطريقة التي يتم بها مصدر البيانات ، والتي أصبحت جميعها قابلة للاستبدال؟ ثم ، من أجل الترقية بسلاسة مع 1.0 ، حدد dva على أنه التركيبة الافتراضية من dva-core و saga؟

لا أعرف ما إذا كان التغليف الأساسي مناسبًا لدعم نوع الإرسال لنوع المثيل؟

dispatch({
  type: model => model.product.loadAll,
})

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

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

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

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

xufei أنا آسف ، شعرت أيضًا أنه يجب أن تشير إلى الكتابة في ts ، لكنني لا أعتقد أنه ضروري. بعد كل شيء ، واجهة dva بسيطة أيضًا ، ولا يمكن إعادة كتابتها باستخدام ts بسبب اكتب الملفات.

sorrycc Separating saga أقدم أيضًا مثالاً ، صحيح أن جوهر dva هو redux + redux-saga ، ولكن من منظور التنفيذ ، يمكننا فصلها إلى مكونات إضافية عن طريق خطافات رد الاتصال.

هل يمكن دعم Immutable.js؟

دعم Immutable.js، Immutable.js له دور بارز في تحسين الأداء

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

تم إهمال Immutable.js ، كما أن الجمع بين عمليات التخزين والانتشار يمكن أن يحقق تأثيرات ثابتة. ولوداش مدمج بشكل أساسي.

في الواقع ، تعد تجربة تطوير dva 1.x جيدة جدًا بالفعل ، على غرار ما إذا كنت ستدعم Immutable.js ، و Split saga ، و ts الدعم المحلي ، فهي تبدو غير ضرورية ، وكلها تنتمي إلى المطوِّر المحب لذاته ، وليس كثيرًا إلى كفاءة التطوير والخبرة الفعلية.

شخصياً ، هناك 4 نقاط يجب مراعاتها بواسطة dva 2.x:

1. تحسين طبقة الخدمة ، سواء كان من الممكن استخراجها في النموذج ، وتعبئتها بطريقة موحدة ، لا تهتم بشكل أساسي بـ request ، ثم قم بتوفير معالجة استثناءات الشبكة افتراضيًا ، والآن تحتاج بشكل أساسي لكتابة request.js بنفسك ؛

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

3. إنه بناء المجتمعات المحيطة بـ dva. في الوقت الحاضر ، أنواع السقالات غنية بالأمثلة ، ولكن هناك حاجة إلى مزيد من البناء. يبدو أن الهدف هو الوصول إلى مستوى الموارد في المجتمع الزاوي أو رد الفعل نفسه.

4. لا يزال تحسين أدوات البناء والأداء والوظائف وما إلى ذلك (وهمي حاليًا) أمرًا مزعجًا بعض الشيء

بالنسبة لي ، أكثر ما يقلقني هو فصل router . أعتقد أن dva يحتاج فقط إلى تضمين redux + redux-saga . يدافع المجتمع redux عن القيام بأقل قدر ممكن ، لذا فإن التعبئة 1.x react-router و fetch تبدو غير ضرورية ، بالإضافة إلى Immutable المذكورة أعلاه. هذا ينتمي إلى تفضيل المطور. بصفتك مشرفًا ، لا ينبغي أن يميل. لتفضيل المطور ، يمكن دعمه في شكل مكونات إضافية. هناك أيضًا مشكلة طبقة الخدمة. إذا لزم الأمر ، يمكنك كتابة plugin بنفسك ، ولا يجب تضمينها في dva-core

nihgwu ما هو الغرض من استخراج أجهزة التوجيه؟ يجب دمج

لقد فعل أمرهم ، فلا أعرف ما هو المبدأ.ولكن إذا تم تفصيل المستند ، فمن الممكن أيضًا

ما هو الغرض من إزالة جهاز التوجيه

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

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

أعتقد أن dva يمكنه فعل المزيد.

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

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

إذا كنت ترغب في حل كامل ، يمكنك تنفيذ dva-ant = dva-core + dva-plugins لاستخدامك الخاص

يجب أن يكون الجمع بين dva عبارة عن مزيج من redux و saga ، لأن هذين هما جوهر تدفق حالة البيانات ، ولا يمكن اعتبار الآخرين إلا أجهزة طرفية مبنية على البيانات ، ويمكن دعمها بواسطة المكونات الإضافية أو طرق أخرى. يمكننا مقارنة Express و Django ، الاختلاف النموذجي بين فعل القليل والقيام بالمزيد ، فبعض الأشخاص يحبون الكبار والكامل ، لكن مجتمع js يحترم الصغر ولكن الجميل

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

إذا فعلنا المزيد بشكل أعمى ، فستصبح سيناريوهات تطبيق dva أضيق وأضيق. على سبيل المثال ، لا يمكن استخدام جهاز التوجيه التفاعلي في RN (الإصدار 4 يدعم بالفعل ولكنه أساسي جدًا) ، كما يأتي RN مع الجلب ، وهناك روابط قوية أخرى . ستتسبب المكتبة أيضًا في مشاكل تبعية الترقية. لا تزال عبارة عن جهاز توجيه متفاعل. V4 يدعم RN ، لكن dva لا يزال V2. علينا انتظار dva لترقية جهاز التوجيه التفاعلي قبل استخدامه. إذا كان مكونًا- في والترقية بشكل مستقل ، لن تكون هناك مشكلة من هذا القبيل. NS

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

2:00:
1. في التطوير الفعلي ، يتم تطبيق منطق الأعمال في النموذج ، والملف كبير جدًا ، ما هي العلاقة بين الآخر والخدمة؟ يمكن أن تكون الخدمة أو الطلب مدمجًا
2. قم بتغيير جهاز التوجيه إلى البرنامج الإضافي الخاص بالنظام ، أو أيًا كان الغرض منه هو تحرير التبعية

متى سيبدأ الإصدار 2.0؟

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

TypeScript و RN.نأمل في الحصول على دعم أفضل

فكر في خيار آخر ، قدم namespace افتراضيًا

في عملية استخدام dva ، ستكون هناك دائمًا حالات لا يتطلب فيها reducer أي بادئة ، ويجب أن يوفر التطبيق الحالي لـ dva namespace ، لذلك لدي اقتراح ، إذا كان namespace هو default (أو global ، * ) ، نعتقد أن model أقل من reducers بدون بادئة

فكر شخصيًا في بضع نقاط:

• لا تعتمد على redux-saga ، لذا يمكنك بسهولة إضافة بعض الميزات (مثل دعم غير متزامن / انتظار)
• تقسيمها إلى عدة وحدات صغيرة (على سبيل المثال ، متجر واحد ، جهاز توجيه واحد)
• دعم نموذج متداخل

قمنا مؤخرًا بتصميم نموذج vuex استنادًا إلى redux وكتبنا نقطة مرجعية: https://github.com/d-band/yax

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

هل يمكنني تعيين اسم دليل المسارات؟ على سبيل المثال ، استخدم الحاوية
في الواقع ، أريد تقسيم الكتالوج حسب الوظيفة ، ووضع النموذج والخدمة والحاوية معًا ، وإلا فإن الانتقال إلى عدة كتالوجات سيدمر تدفق القلب. من أجل معرفة ما الذي فتحه user.js في علامة التبويب أعلى sublime ، قمت بالفعل بتسميته على النحو التالي: user.jsx ، user.model.js ، user.service.js. اجمع user / model.js و service.js و container.js

يتم الآن دعم منظمات الدليل مثل zheeeng ، وليس لدى dva قيود على تنظيم الدليل.

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

عند إلغاء التصميم ، هل تفكر في دعم تمرير مخفض لتدمير بيانات الحالة غير المستخدمة؟

التحكم اليدوي مزعج للغاية ، يوصى بتنفيذ مجموعة GC مباشرة

الرجاء ترقية pathToRegexp ، فلا يمكن استخدام طرق التحليل والتجميع الخاصة به بشكل مباشر

الاتفاق أفضل من التكوين ، مما يقلل من الاقتران بالمشاريع الأخرى أو مكدسات التكنولوجيا.

إن تأثير الأعمال ثقيل للغاية ، وفكرة تمديد النموذج جيدة جدًا

يوافق nihgwu شخصيًا على أن "جوهر

sorrycc هل

آمل بشدة أن يتمكن dva-cli من اختيار إنشاء TypeScript المعيارية

يمكن استخدام dva-core بالفعل في تطبيقات WeChat الصغيرة

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

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

نأمل في دعم dva-cli لدعم القلم

دعم SSR لا.

كيفية تكوين إدارة الموارد البشرية ، كتابة API قليلة نسبيًا