Ember.js: [Glimmer 2] "إعادة عرض التراجع" أصبح الآن تأكيدًا

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

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

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

joukevandermaas لا يُعد run.next () إصلاحًا رائعًا لهذا الخطأ ، على الرغم من أنني أفهم أنك إذا كنت غارقة في هذه الأخطاء ، فلماذا تذهب إلى هناك. من الأفضل محاولة فهم سبب إبطال التدفق العكسي للبيانات الأشياء التي تم تقديمها بالفعل.

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

joukevandermaas لا يُعد run.next () إصلاحًا رائعًا لهذا الخطأ ،

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

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

باعتباري شخصًا يتابع Ember على نحو وثيق نسبيًا (Twitter ، هنا على github ، والقوائم البريدية ، وما إلى ذلك) فقد تسللت هذه المشكلة إلي ، لذا أظن أن هذا قد يفاجئ الآخرين إذا هبط كجزء من Ember 2.10 ، خاصةً بسبب يشير تحذير الإيقاف المرتبط به على وجه التحديد إلى أن السلوك سيتم دعمه حتى 3.0. لا أعتقد أنني رأيت أنه اجتماعيًا في أي مكان أن هذا السلوك لن يعمل في Glimmer 2 (على الرغم من أنني ربما فاتني ذلك ببساطة).

تشك في أن هذا قد يفاجئ الآخرين إذا هبط كجزء من Ember 2.10 ، لا سيما لأن تحذير الإيقاف المرتبط به ينص على وجه التحديد على أن السلوك سيكون مدعومًا حتى 3.0. لا أعتقد أنني رأيت أنه اجتماعيًا في أي مكان أن هذا السلوك لن يعمل في Glimmer 2 (على الرغم من أنني ربما فاتني ذلك ببساطة).

نعم ، نحن بحاجة إلى تحسين بعض الرسائل / التفاصيل هنا.

أرى أن هذا جعله في الإصدار 2.10. هل سيتم ذكر ذلك في منشور مدونة الإصدار 2.10؟

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

لدي نمط استخدام يتأثر بهذا. أنا متأكد من أن المشكلة يجب أن تكون نمط الاستخدام الخاص بي ، وليس هذا التغيير بالذات ، لكني أحب بعض المدخلات حول ما سيكون نمط الاستخدام البديل الجيد!

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

 filteredModel: Ember.computed('model', /*list of individual query params*/, function(){
    let model = this.get('model').filterBy('pdf.pdf_path.url'); //removes all records that don't have a pdf uploaded
    this.get('queryParams').forEach((filter)=> { // for each possible filter
      if ((this.get(filter).length > 0)) { //if the filter has content...
        //guardian pattern to prevent invalid inputs
        let valid = new RegExp('^[A-Za-z0-9 _]*[A-Za-z0-9][A-Za-z0-9 _]*$');
        while (this.get(filter).length > 0 && !valid.test(this.get(filter))){
          this.set(filter, this.get(filter).slice(0,-1));
        }
        //block of code where the model gets filtered
        //...
        //...
    });
    return model;
  }),

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

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

revanar يمكن أن أكون بعيدًا تمامًا هنا ، ولكن يبدو أن CP الخاص بك هو في الواقع شيئان مختلفان: CP لإرجاع النموذج المفلتر والآخر لتحديث المرشحات. أود نقل جزء تحديث المرشحات إلى جزء يمكن ملاحظته. أو ، إذا كان هذا مكونًا وكنت تقوم بتمرير معلمات الاستعلام إلى المكون ، فسأقوم بنقل المنطق إلى الخطاف didReceiveAttrs . من واقع خبرتي في الوقوع في خطأ "إعادة الإرسال إلى الوراء" ، أعتقد أن نقل العملية set خارج CP يجب أن يزيل الخطأ.

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

Assertion Failed: You modified transitioningIn twice on <app<strong i="6">@component</strong>:link-to::ember1159> in a single render.

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

لست متأكدًا من كيفية متابعة استكشاف الأخطاء وإصلاحها.

ذكرت chancancode علامة ميزة لتعطيل خطأ الإيقاف هذا ، لكنني لا أرى أي معلومات عنها في https://github.com/emberjs/ember.js/blob/master/FEATURES.md. هل يعرف أحد ما هو العلم؟

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

1. رمز التغليف بـ Ember.run.next
2. نقل أي كود setter من computed properties إلى خطافات دورة الحياة ، أو إلى event handlers ، حيثما أمكن ذلك.
3. تجربة مجموعة مختلفة من خطافات دورة الحياة للمكونات

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

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

لدى Kris Selden نصيحة مفيدة لتصحيح هذه الأخطاء:

لقد أوجزت الخطوات بمزيد من التفاصيل هنا: https://github.com/GavinJoyce/backtracking/pull/1#issuecomment -266427152

أنا أعمل على تحسين رسالة تأكيد التراجع . لقد قطعت بناء 2.10.2-with-improved-backtracking-assertion يتضمن هذه الرسائل الأفضل:

قبل:

لقد قمت بتعديل message.message_goal.description مرتين على <(subclass of Ember.Model):ember3486> في تصيير واحد. كان هذا غير موثوق به وبطيئًا في Ember 1.x ولم يعد مدعومًا. راجع https://github.com/emberjs/ember.js/issues/13948 لمزيد من التفاصيل.

بعد، بعدما:

لقد قمت بتعديل message.message_goal.description مرتين على <(subclass of Ember.Model):ember3486> في تصيير واحد. تم تقديمه في component:message-edit-expanding-container-component وتم تعديله في component:rules/predicate-date-value-component . كان هذا غير موثوق به وبطيئًا في Ember 1.x ولم يعد مدعومًا. راجع # 13948 لمزيد من التفاصيل.

لدي بعض الأشياء الأخرى التي يجب القيام بها قبل أن يصبح جاهزًا ، ولكن سيكون من المفيد حقًا إذا جرب عدد قليل من الأشخاص ذلك في تطبيقهم. / ccfivetanley ، bryanhickerson ، revanar ، phammers ، scottmessinger ، @ tharrington1 ، @ manimis902 ، jakesjews ، @ elwayman02. يرجى إعلامي إذا رأيت أي رسائل تأكيد غير مثالية في تطبيقك.

لتجربتها ، قم بتحديث bower.json لتضمين تبعية العضو على النحو التالي:

{
  "name": "backtracking",
  "dependencies": {
    "ember": "intercom/ember#2.10.2-with-improved-backtracking-assertion",
    "ember-cli-shims": "0.1.3"
  },
  "resolutions": {
    "ember": "2.10.2-with-improved-backtracking-assertion"
  }
}

يمكنك الاطلاع على مثال لتطبيق يقوم بتشغيل هذا الإصدار هنا: https://github.com/GavinJoyce/backtracking/pull/10

لقد قطعت للتو بناء 1.11.0-canary

هل هذا خطأ مطبعي؟

rwjblue شكرا ، كان هذا خطأ مطبعي. محدث

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

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

FWIW لقد وجدت مشكلة أخرى تتعلق بهذا: https://github.com/alexspeller/ember-cli-active-link-wrapper/issues/25

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

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

^ لقد أخذنا بعض الوقت للغوص في مشكلات الأوراق الورقية (https://github.com/miguelcobain/ember-paper/pull/590). يبدو أن:

• كانت رسائل الخطأ الجديدة مفيدة أكثر من الرسالة الحالية
• لم يكونوا مثاليين لأنهم لم يتعاملوا مع المحتوى المنتَج جيدًا. (تم الإبلاغ عن المكون الذي يحتوي على {{yield}} على أنه المصدر الذي كان مفيدًا ، ولكنه ليس مفيدًا كما قد يكون)

قد يكون أو لا يكون خطأ في الملحق ، لكنني واجهت هذا الخطأ في https://github.com/DockYard/ember-one-way-controls/issues/136

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

في الوقت الحالي ، أحاول التخلص من الخلطات ، لذا سأقتله ببساطة وسأعمل على حل المشكلة.

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

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

@ tundal45 ، هل يمكن أن تكون قادرًا على إنشاء Twiddle أو نموذج تطبيق يوضح ما تعتقد أنه خطأ غير صحيح؟

@ Blackening999 @ tundal45 هل يمكنك تقليل حالة الاستخدام الخاصة بك إلى لغز؟

chancancode @ Blackening999 سأحاول نشر واحدة هنا قريبًا. شكرا للإستجابة السريعة.

chancancode https://ember-twiddle.com/936d549b5625b0cf4f3c945d0ed04d3b؟openFiles=components.button-with-state.js سيكون الوسيط ولكني لا أرى الخطأ الذي أراه في التطبيق لذلك قد يكون شيئًا آخر يسبب ذلك.

أرى هذا في العديد من الخصائص المحسوبة ، أحدها بسيط Ember.computed.or . نظرًا لعدم إمكانية تطبيق أي من اقتراحات @ manimis902 في هذه الحالة ، فما الحل المناسب؟

كما ذكرت @ tharrington1 أين هي علامة الميزة التي ذكرها chancancode ؟

cbou بقدر ما أعرف أن العلم غير موجود

لم أكن متأكدًا تمامًا من كيفية التعامل مع إشعارات الإيقاف هذه ، ولست متأكدًا مما إذا كان الإصلاح الخاص بي صالحًا أم لا ، لكنني كنت أقوم بطلب AJAX في ربط المكون init() والذي أدى إلى تغيير القيمة في شكل مختلف خاصية الخدمة (لتتبع / إظهار في حالة الوصول إلى الخادم البعيد).

لقد قمت بنقل كود طلب AJAX الخاص بي من خطاف المكون init() إلى رابط المكون didRender() ويبدو أنه تم حل إشعار الإيقاف الخاص بي.

@ lvl99 فعلت نفس الشيء.

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

يحتوي المثال المحدد على مكونين ( person-detail و address-detail ) مسؤولان عن إنشاء أخطاء التحقق الخاصة بهم. يتم تتالي أخطاء التحقق التي تم إنشاؤها بواسطة address-detail لتتضمن المكون ( person-detail ) عبر إجراء تم طرحه ضمن الخاصية المحسوبة errors . يتم عرض الأخطاء الناتجة عن كل مكون داخل مكون error-displayer بمساعدة المساعد error-formatter . الكود المقدم يعمل كما هو متوقع كما ترى.

لكن؛ لدينا تحذير من الإيقاف على النحو التالي: DEPRECATION: The error property ofis an Ember.Binding connected to validatable.errors.name , but Ember.Binding is deprecated. Consider using an alias computed property instead. [deprecation id: ember-metal.binding] See http://emberjs.com/deprecations/v2.x#toc_ember-binding for more details. لتجنب ذلك ؛ يرجى الدخول إلى المساعد error-formatter والتعليق على السطر رقم 9 وإلغاء التعليق رقم 8 حتى نقوم بما هو مقترح في شرح التحذير.

الآن وصلنا إلى Assertion Failed: You modified "error" twice on <Ember.Object:ember338> in a single render. It was rendered in "component:error-displayer" and modified in "component:error-displayer". This was unreliable and slow in Ember 1.x and is no longer supported. See https://github.com/emberjs/ember.js/issues/13948 for more details. سيئ السمعة ونحن نفهم سبب حصولنا على هذا الخطأ ؛ لأن الإجراء الذي يتم تشغيله داخل address-detail s errors أدى إلى إعادة حساب الخاصية المحسوبة errors person-detail والمحتوى الذي تم عرضه بالفعل تسبب في حدوث هذا الخطأ . إليك ما نود أن نتعلمه:

1. Ember.Binding مقابل Ember.computed.alias بشكل مختلف تمامًا بالتأكيد فيما يتعلق بمرحلة إعادة الحساب (إعادة العرض). ما هو الفرق الدقيق؟ يبدو أن اقتراح استخدام الأخير كبديل للأول بمثابة كسر للشفرة ؛ على الأقل لحالتنا.
2. هل تشغيل إجراء من داخل خاصية محسوبة يمثل مشكلة؟ اذا نعم؛ ما هي الاقتراحات الممكنة لتجنبه؟
3. نحن نفكر في إجراء التفاف يؤدي إلى إصدار كشف Ember.run.scheduleOnce('afterRender', ...) . هل هذا هو الطريق الصحيح للذهاب؟
4. أخيرا؛ يرجى الرجوع الآن إلى كسر الكود واكتب شيئًا في أي حقل ؛ والمثير للدهشة أن المكونات يتم إعادة تقديمها عدة مرات ؛ نشك في أن هذا قد يكون مرتبطًا بخلل.

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

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

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

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

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

@ feanor07 Ember.run.scheduleOnce... لم ينجح ، ولكن إضافة Ember.run.schedule("afterRender", () => { ... }); واحد فقط إلى الخاصية set المشار إليه أولاً بواسطة تتبع المكدس أزال العديد من رسائل الخطأ التي تتتالي بعد الرسالة الأولية.

neilthawani قد يخفي الخطأ ، لكنه لا يحل المشكلة بالضرورة. يُقصد بالخطأ الإشارة إلى أنك تقوم بتعيين قيمة مرتين في حين أنه من المحتمل أن تقوم بتعيينها مرة واحدة فقط. بوضع واحد من set في schedule ، فأنت تؤخر المجموعة الثانية فقط بحيث تحدث في حلقة تشغيل مختلفة. لم تقم بإصلاح المشكلة الأساسية المتمثلة في العرض مرتين عندما تحتاج فقط إلى العرض مرة واحدة ، فقط خدعت Ember لعدم معرفة وجود مشكلة لأن العروض تحدث الآن في حلقات تشغيل منفصلة.

@ elwayman02 اه اه. شكرا. في الأساس غاب عن النقطة تماما.

تحرير: بعد أن واجهت صعوبة في ذلك ، قمت بإدخال عدد قليل من afterRenders أكثر مما كنت مرتاحًا له. لدينا معالج click على أحد مكونات البيانات الخاصة بنا والذي يقوم بتبديل تلميح الأدوات. سمح لنا تعيين علامة isDisplaying ضمن Ember.run.schedule("afterRender", () => { ... }); بتصحيح المشكلة الحقيقية ، والتي كانت في الواقع رجوعًا في وحدة التحكم التي تستدعي كلاً من مكون البيانات ومكون تلميح الأدوات.

tl ؛ dr: لم أحتفظ به هناك (تلقيت خطأ Maximum call stack size exceeded مرة واحدة أيضًا) ، لكن استخدامه كان مفيدًا في تصحيح الأخطاء حتى تم الكشف عن المشكلة الحقيقية.

PSA لأي شخص آخر يقوم بالترقية الآن: خطأ التأكيد المحسّن "backtracking re-render" الذي تم ذكره بواسطة GavinJoyce أعلاه مدرج بالفعل في Ember 2.11. كما تم اقتراح أن القفز مباشرة إلى 2.11 قد يكون مفيدًا.

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

أيضًا ، في النهاية الخلفية لدي ، أستخدم .Net Core مع JSON API .Net Core (https://github.com/Research-Institute/json-api-dotnet-core) - باتباع إرشاداتهم.

يتم تعطيل عرض واجهة المستخدم في هذه المرحلة ، ولكن يتم تحميل البيانات ويمكنني رؤية القيم المطلوبة.

    // Profile Model:
    import DS from 'ember-data';
    export default DS.Model.extend({
        'firstName': DS.attr(),
        'lastName': DS.attr(),
        'applicationUser': DS.attr(),
        'contactProfile': DS.belongsTo('address', {
            async: true
        }),
        'companyProfile': DS.belongsTo('address'),
        'companyMailingAddress': DS.belongsTo('address'),
        "companyPhysicalAddress": DS.belongsTo('address')
    });

    // Address Model:
    import DS from 'ember-data';
    export default DS.Model.extend({
        'address1': DS.attr(),
        'address2': DS.attr(),
        'city': DS.attr(),
        'state': DS.attr(),
        'zipCode': DS.attr(),
        'country': DS.attr(),
        'website': DS.attr(),
        'phoneNumber1': DS.attr(),
        'phoneExtension1': DS.attr(),
        'phoneNumber2': DS.attr(),
        'phoneExtension2': DS.attr(),
        'email': DS.attr(),
    });
    // Adapter settings
    import DS from 'ember-data';

    export default DS.JSONAPIAdapter.extend({
        namespace: 'api/json',
    });
    DS.JSONAPISerializer.reopen({
        keyForAttribute(key) {
            return key;
        },
        keyForRelationship(key) {
            return key;
        }
    });
    // Route
    import Ember from 'ember';

    export default Ember.Route.extend({
        model() {
            return Ember.RSVP.hash({
                profile: this.store.findRecord('profile', 1)
            });
        }
    });

    // Template
   {{model.profile.contactProfile.address1}}

والخطأ الذي أحصل عليه:
فشل التأكيد: لقد قمت بتعديل "model.profile.contactProfile" مرتين فيmodel: profile :: ember543: 1> في تصيير واحد. تم تقديمه في " template: fuels-ember / internal / profile / template.hbs " وتم تعديله في " template: fuels-ember / internal / profile / template.hbs ". كان هذا غير موثوق به وبطيئًا في Ember 1.x ولم يعد مدعومًا. راجع https://github.com/emberjs/ember.js/issues/13948 لمزيد من التفاصيل.

ملاحظة: لقد حاولت استخدام طريقة Ember.computed للحصول على الملكية ، ويبدو أن هذا يعمل. هل هذا مطلوب؟

تحديث: لقد اكتشفت أيضًا أن البيانات يتم تحميلها بشكل جيد داخل {{#each}} المساعد ، ولكن ليس مباشرة في النموذج.

تضمين التغريدة
ربما يكون مرتبطًا بـ https://github.com/emberjs/data/issues/5023 حيث تحدث إعادة العرض التراجعي بسبب العلاقات في استجابة jsonapi التي تحتوي على مجموعة خصائص links .

كانت هذه هي المشكلة بالنسبة لي ، والتي بدأت بعد Ember Data 2.13.2. حاول استخدام بيانات ember: 2.13.2 لترى ما إذا كان هذا يحل مشكلتك.

@ daniel-de-wit ممتاز هنا - هذا يعمل بالفعل. إنه يفعل الآن ما أحتاجه للقيام به وأنا سعيد به.

lbarsukov @ daniel-de-wit لقد أصدرنا نسخة جديدة من بيانات ember تعمل على حل هذه المشكلة.

lbarsukov أعتقد أن هذا له علاقة belongsTo hasMany .

لنفترض أن لديك نموذجين ، سؤال وجواب. إذا قمت بإرجاع 10 إجابات على السؤال ، ولكن كل مُسلسل سؤال يشير إلى إجابته ، عليك أن تحدد العلاقة بشكل صحيح.

// Question Model:
    export default DS.Model.extend({
        'answers': DS.hasMany('answers'), // if you never reference question.answers you can omit this
        ...
    });

// Answer Model:
    export default DS.Model.extend({
        'question': DS.belongsTo('question'),
        ...
    });

عندما تأتي البيانات عبر تحديد أزواج متعددة من الأسئلة / الإجابات ، مع توقع علاقة 1-1 في حالة عدم وجودها ، فإنها تستنتج أن السؤال قد تم تعديله في منتصف العرض.

من المنشور الأولي ، تم ذكر بعض الخطافات:

هذا مثال متطرف جدًا ، لكنه يوضح المشكلة. بالإضافة إلى init ، فإن didInitAttrs و didReceiveAttrs و willInsertElement و willRender يحدث أيضًا بشكل متزامن أثناء عملية العرض. بالإضافة إلى ذلك ، غالبًا ما يكون التراجع مشكلة تنشأ عن سلوك الخصائص ذات الاتجاهين.

لماذا تعمل الخطافات didInsertElement و didRender مثل السحر لكن الخطافات الأخرى تفشل مع ظهور خطأ twice render ؟

BenjaminHorn @ Blackening999DhaulagiriDingoEatingFuzz @ Gaurav0GavinJoyceRedsandroTRMW @ Turbo87aklkvalidcastanobackspacebdizbgentrybjornharrtellbryanhickersonbuschtoenscaseklimcbouchancancodedanaoira @ دانيال دي خفة دمfivetanley fotinakisgabrielgrantghostjakesjewsjanmisekjoukevandermaas هذا لا تزال قضية، ربما علينا أن نهايته، ما رأيك؟

أصلحت أي حالات خطأ في تطبيقي.

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

نعم ، من فضلك أغلق

نهاية حقبة 😬

👍

آسف لطرح قضية قديمة.

قل على سبيل المثال أنا أقوم بالتقديم

{{this.myBool}}

والخطأ هو Error: Assertion Failed: You modified "myBool" twice

يمكنني إصلاح الخطأ بتغييره إلى:

{{if this.myBool true false}}

وبالمثل ، إذا كان ربط اسم الفئة يسبب المشكلة

يمكنني تغيير:

classNameBindings: ['myBool']

إلى

classNameBindings: ['myBool:yes:no']

إذا كان بإمكاني إسكات التحذير مثل هذا ، فلماذا لا يستطيع Ember التعامل معه؟

هذا هو الكود التجريبي الذي كنت أستخدمه:

https://ember-twiddle.com/db7f6e382bd0b1de91447881eebb62a5؟openFiles=templates.components.my-component.hbs٪2C

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

نعم. شكرا لك. أتفهم مشكلة التراجع الموضحة في هذا المنشور الأصلي لأنه يحتوي على set صريح

لكن في لغتي التجريبية ، لا يوجد set بقدر ما أستطيع رؤيته.

_Edit_ لقد جاء ذلك بشكل خاطئ ، أعني أنه لا يوجد set قادم من جزء _ لاحق_ من القالب كما هو موجود في المثال

حسنًا ، أنا لا أحصل على الخطأ في العبث ، ما هو تسلسل النقرات الذي يجب أن أفعله؟

انقر فوق فتح ، ثم انقر فوق إغلاق. لكن زر الإغلاق للمكون الفرعي الناتج ، وليس الأصل.

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