<p>اقتراحات تحسين dva</p>

أعتقد أنه يمكنك تلبية احتياجاتك بشكل أساسي باستخدام تمديد نموذج dva.

@ iceberg211 أشعر باختلاف ، dva-model-extends تعادل الميراث ، وبنية البيانات هي نفسها النموذج. وما طرحته هنا منظم من خلال وحدات ، في الواقع ، الوحدات عبارة عن هيكل تنظيمي افتراضي.

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

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

يمكن تحقيق ذلك من خلال هذه الخاصة بي
https://github.com/fangkyi03/dvajs

هذا أيضًا هو السبب وراء استخدام المزيد والمزيد من مشاريع vue للتخزين والتفاعل مباشرة مع mobx.

كيف توصلyeatszhang إلى هذا الاستنتاج؟ هل لديك بيانات؟

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

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

{
  namespace: 'user',
  state: { },
  userList: {
    before() { },  // 同步，函数显示loading
    after(){}, // 同步，隐藏loading
    *retrieve() {}, // 异步, 请求读取列表
    *create() {}, // 异步，创建用户
    *update(){}, // 异步，更新用户信息
    saveModal(){}, // 同步，显示或者隐藏modal
    successMessage(){}, // 模块内可复用的消息提示
    failMessage() { }, 
  },
}

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

لقد أجريت بعض التحسينات على dva واستخدمت البرامج النصية لإنشاء js المقابل تلقائيًا لواجهة API الخلفية.
https://github.com/fangkyi03/swaggerToTypeScript

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

api.sendData (هذا ، [
api.
هذا هو التأثير الجانبي. يمكن معالجة كل طلب شبكة بشكل منفصل ، مثل onCallBack ، و onError ، و timeOut ، وما إلى ذلك.
)
])

مثال على الإنشاء التلقائي لوثائق واجهة API

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

وإذا كنت تستخدم استدعاء العائد لإصدار حكم واحد ، فلا يزال من الممكن استخدام واجهات 2-3.إذا كان هناك العديد من الواجهات ، فأنت بحاجة إلى ضمان دقة البيانات. تحتاج إلى الحكم على ما إذا كان الرمز هو 200 لكل واجهة. هذا حقا مزعج.

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

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

• التراجع ، لقطة
• سهل الاختبار
• إعادة تحميل الساخنة
• devtools

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

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

الرأي الشخصي هو بشكل أساسي لوضع إعادة التشغيل ، وليس dva

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

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

بالإضافة إلى ذلك ، أود أن أقول إن mobx ممتاز حقًا ، لأنه أكثر إيجازًا من redux ويوصى به مؤلف redux.أعتقد أن المزايا على النحو التالي

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

بادئ ذي بدء ، خطتي هي استخدام البرنامج النصي الذي كتبته مباشرة للزحف إلى واجهة API الخلفية إذا كانت النهاية الخلفية الخاصة بك مبهرجة ، ثم إنشاء مستند api المقابل مباشرةً محليًا عندما تحتاج إلى الاتصال بالواجهة مباشرة
api.send (هذا ، [
api.cart ('cartModel'). getCartList () ()
])
تعتمد جميع الأسماء هنا على اسم واجهة الواجهة الخلفية. إذا لم يكن من السهل فهمها ، فأنا لا أعتقد أن مستند swagger يحتاج إلى القراءة لأنه عند النقر فوق مستند swagger ، يمكنك رؤية اسم الواجهة المقابلة على جانب عنوان url. يمكنك مقارنتها مباشرة لمعرفة الواجهة ، وبسبب المستند الذي تم إنشاؤه تلقائيًا بواسطة واجهة برمجة التطبيقات المباشرة ، إذا كنت تريد عرض التفاصيل ، فانقر مباشرة لمشاهدة التفاصيل.

أليس من الممكن معرفة ما يفعله هذا API؟

ثانيًا ، لقد قمت بفصل أكثر تجريدًا للسلوكيات الشائعة.يمكنك تجاوز البرنامج النصي API لتركيب المزيد من وظائفك. يمكنك التحكم في عرض أو عدم عرض النموذج المقابل مثل هذا.
api.toggleModalShow (thz، modelName، state) {
thz.props.dispatch ({type: ${modelName}/setValue ، الحمولة: {
هو ShowModal: state
}
}

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

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

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

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

هل قرأت أن dvajs التي كتبتها يمكن أن تحل المشاكل التي تواجهها بسهولة

@ fangkyi03 لا ، ما هو الشيء الجيد فيك؟

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

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

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

على سبيل المثال ، عندما تم إنشاء النموذج الخاص بي على هذا النحو

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

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

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

مشروعي هنا هو ملف نموذج لأنه يُستخدم لطلبات الشبكة

يتم إنشاء جميع أجزاء mdoel الأخرى مباشرة مثل هذا

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

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

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

ربما فهم @ fangkyi03 ما قلته ، ما

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

@ fangkyi03 لذا dva واحدة تلو الأخرى ،

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

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

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

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

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

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

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

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

لذلك قلت إنك ما زلت لا تفهم فكرتي الأساسية. ما أعنيه هو أن النموذج يُستخدم فقط كمتجر للاستخدام. كما أنه ليس شائعًا في الوقت الحاضر مثل المكونات عديمة الحالة. ومن الجيد أيضًا التخلي عن الحالة والاستخدام الخاصيات ، على الرغم من أن بعض الفتحات في إعادة الإرسال ستؤدي إلى بعض الحسابات الزائدة ، ولكن لا يزال من الممكن تقدير مقدار الحساب. بعد كل شيء ، يتم استخدام نموذجك فقط لتخزين البيانات ولن يكون هناك معالجة منطقية زائدة عن الحاجة. في الواقع ، ينعكس مقدار الحساب بشكل أساسي في فتحة إعادة الإرسال هذه عندما تبدأ إرسالًا. في ذلك الوقت ، ستشارك كل عمليات التخفيض وجميع المراقبة وجميع البرامج الوسيطة في الحساب ، لذلك كتبت fastDva لهذا ، فقط الاحتفاظ بالأجزاء المطلوبة في المشروع الفعلي ، وتم إهمال الأجزاء الأخرى ، مما يؤدي إلى تحسين أكبر ويمكن أن يكون أكثر ملاءمة لي الآن.
https://github.com/fangkyi03/fastdva-core

لذلك سأحول كل dva إلى fastDva الذي كتبته في المستقبل

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

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

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

التفكير الهندسي لشركة Angular أفضل بكثير في هذه المرحلة ، ما عليك سوى اتباع النموذج وكتابته. ثكنات من حديد وجنود مياه جارية ~

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

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

السيناريوهات التي تتطلب وجود dva:
1. تحتوي الصفحات المختلفة ، وخاصة المكونات المتقاطعة ، على مصادر بيانات مرتبطة أو يمكنها الاشتراك في نفس مصدر البيانات.
2. تحتوي المكونات أو الصفحات المختلفة على نفس البيانات والمنطق في طريقة العرض الجديدة.
في [2] ، لماذا أقول أن هناك مكونات وصفحات مختلفة ، لأن التفاعل مكون من مكونات ، وجزء من وظيفة نموذج العرض القابلة لإعادة الاستخدام محاط مباشرة بالمكون. يستخدم yeatszhang ng mvvm أو mvc للاستفادة أكثر من التفاعل لأن ng لا يغلف البيانات في أحد المكونات. ng يعتمد على البيانات ، ويستند التفاعل على المكونات. تتمثل ميزة استخدام البيانات كوحدة في فصل الصفحات ، وهناك المزيد من الأماكن لإعادة استخدام معالجة البيانات. السعر هو أن بعض الصفحات تحتاج إلى أن تقترن بالبيانات وأن يتم فصلها أيضًا. يجب عليك كتابة رمز لقرصها سويا.
لذلك ، يتم أيضًا تقليل سيناريوهات الاستخدام الخاصة بـ [2] بشكل كبير.

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

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

و

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

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

إحياء عجلات جديدة. . . ريكتكس

اطرح سؤالاً ، هل يمكن أن يكون لتأثيرات إعادة المباراة قيم عودة ، هل يمكن أن يكون لتأثيرات dva؟

اطرح سؤالاً ، هل يمكن أن يكون لتأثير إعادة المباراة قيمة مردودة ، هل يمكن أن يكون لتأثير DVA ذلك؟

يمكن للتأثير إرجاع البيانات في شكل وعد

@ fangkyi03 أفهم ، شكرا لك.

كل ما أريده هو مساحة اسم متداخلة.
مثال:

const model = {
  namespace: 'foo',
  model: {
    namespace: 'bar',
    state: {
      msg: "Hello, World!"
    }
  }
}

احصل على msg foo.bar.msg

ما ورد أعلاه مجرد مثال تقريبي ...

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

يقترح sorrycc تغيير تنسيق النوع من مساحة الاسم / الإجراء إلى action @ namespace ، وهو أكثر دلالات.