استخدم الترميز النقطي للوصول إلى خصائص كائن

(تقرر في التدريج) ✅

لا يقبل هذا التحدي إلا ما يلي كحل:

console.log(dog.name);
console.log(dog.numLegs);

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

console.log(dog.name, dog.numLegs);

أعتقد أنه يجب علينا إما تحديد عبارتين منفصلتين console.log() ، أو إعادة بناء الاختبار لقبول كلا الحلين - أعتقد أنني أفضل الخيار الأخير. أفكار؟

تحقق من مُنشئ الكائن بمثيل :

(تقرر في التدريج) ✅

• لسبب ما ، يقوم linter بإلقاء التحذير Expected an assignment of function call and instead saw an expression عند كتابة الحل الصحيح myHouse instanceof House; . التحدي يمر رغم ذلك.
• أيضًا ، يحتوي رمز البذور نفسه على تحذير من linter عند تحميل فاصلة منقوطة مفقودة.
• أخيرًا في هذا القسم ، لست متأكدًا مما إذا كان متعمدًا ، ولكنه قد يكون مربكًا بعض الشيء - في التحديات السابقة في هذا القسم ، تم تعريف المُنشئين على النحو التالي:

function House(numBedrooms) {
  this.numBedrooms = numBedrooms;
}

لكن في هذا التحدي يتحولون إلى بناء الجملة هذا:

let House = function(numBedrooms) {
  this.numBedrooms = numBedrooms;
}

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

فهم الخصائص الخاصة :

مجرد ملاحظة على هذا ، ولدي فضول لمعرفة الآراء الأخرى - ولكن يبدو أن هذا التحدي يدور أكثر قليلاً حول for...in بدلاً من hasOwnProperty ، و for...in ليس كذلك تم شرحه بشكل كاف في هذا القسم حتى الآن.

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

فهم خاصية المنشئ :

(تقرر في التدريج) ✅

سيمر هذا التحدي بأي من الحلين:

function joinDogFraternity(candidate) {
  if (candidate instanceof Dog) {
    return true;
  }
  return false;
}

// OR:

function joinDogFraternity(candidate) {
  if (candidate.constructor === Dog) {
    return true;
  }
  return false;
}

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

يمكننا فقط إضافة حالة اختبار تقول "message: 'your solution should use the constructor property'" والتحقق منها باستخدام regex.

استخدم الميراث حتى لا تكرر نفسك :

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

تأتي هذه العبارة من التحدي التالي:

سيغطي هذا التحدي التالي كيفية إعادة استخدام أساليب Animal داخل Bird and Dog دون تحديدها مرة أخرى. يستخدم تقنية تسمى الوراثة.

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

ترث السلوكيات من النوع الفائق :

(تقرر في التدريج) ✅

مشكلة بسيطة للغاية هنا - جزء من البذرة لهذا يقرأ كما يلي:

// Add your code below this line

let duck
let beagle

duck.eat(); // Should print "nom nom nom"
beagle.eat(); // Should print "nom nom nom"

هذا يلقي خطأ لينتر. أود أن أقترح ما يلي بدلاً من ذلك:

مشكلة بسيطة للغاية هنا - جزء من البذرة لهذا يقرأ كما يلي:

let duck; // change this line
let beagle; // change this line

duck.eat(); // Should print "nom nom nom"
beagle.eat(); // Should print "nom nom nom"

@ no-stack-dub-sack - هذه كلها نقاط رائعة ، ولم أر أي مشاكل في هذا القسم على الرغم من أنني كنت غير متصل بجزء كبير من الأمس. شكرًا لاستعراض هذا القسم بهذه التفاصيل 👍 إليكم أفكاري (TL ؛ د - أوافق على كل ما ذكرته):

• Use Dot Notation to Access the Properties of an Object : يجب أن تجتاز الاختبارات إذا استخدم أحد الأشخاص كشف حساب console.log .
• Verify an Object's Constructor with instanceof : يجب أن نصلح الفاصلة المنقوطة المفقودة وأن نكون متسقين بشأن طريقة تعريف House . في حين أن هناك طرقًا متعددة للقيام بالأشياء في JS ، فلا داعي لإرباك الأشخاص الذين يتعلمون ذلك لأول مرة.
• Understanding Own Properties : فيما يتعلق بوجهة نظرك حول for...in - لقد أخذنا بوجه عام وجهة النظر القائلة بأنه من المقبول استخدام المفاهيم التي تم تناولها بالفعل في المنهج. يمكن للمخيمين القفز كما يريدون ، ولكن هناك تدفق للمواضيع. (خلاف ذلك ، يمكن أن تصبح التحديات طويلة / متكررة إذا كان عليهم إعادة تغطية الأشياء قبل الوصول إلى النقطة). ومع ذلك ، أعتقد أنه قد يكون من المفيد وضع ملاحظة مباشرة أسفل المثال تشرح بإيجاز بناء الجملة ("تذكر أن for...in يفعل ...)
• Understand the Constructor Property : وافق على النقطة التي تريد إضافتها باستخدام المُنشئ في التعليمات
• Use Inheritance So You Don't Repeat Yourself : نعم ، نقاط جيدة لربط التحديات معًا بشكل أفضل
• Inherit Behaviors from a Supertype : يجب علينا بالتأكيد إضافة الفاصلة المنقوطة ، والتعليقات مفيدة أيضًا

اسمحوا لي أن أعرف إذا كنتم ترغبون في العمل على هذه - أنا أقفز إلى قسم آخر (يمكن أن أعمل على هذا في يوم أو يومين) ، أو يمكننا فتح هذا كما نريد مساعدة 😄

HKuz رائع ، شكرًا! سأُنهي القسم ، وأضيف بعض التعليقات الإضافية إذا كان لدي أي تعليق ، وبعد ذلك يمكننا أن نقرر في هذه المرحلة ، لكنني أعتقد أن فتحه أمام Help Wanted سيكون الأفضل على الأرجح. حسنا ابقي ملصقك.

إضافة طرق بعد الميراث :

هذا التحدي مربك بعض الشيء بسبب حالة الاختبار التالية:

Dog should have the bark() method as an own property.

الحل لهذا الجزء يبحث عن هذا:

Dog.prototype.bark = function() {
    console.log('Woof!');
};

وبينما يقوم Dog.prototype.hasOwnProperty('bark') بإرجاع true (لذلك هذا صحيح بالطبع) ، يأتي مصدر الارتباك من هنا (والذي يأتي من Iterate Over All Properties ):

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

التمييز هو أنه بالنسبة لمثيلات Dog ، bark لن تكون خاصية own ، لكنها _هي_ own خاصية Dog.prototype . لذلك ، هذا محير بعض الشيء بالنسبة لشخص يتعرف للتو على هذه المفاهيم.

أبسط حل هو تغيير حالة الاختبار ليقول:

Dog.prototype should have the bark() method as an own property.

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

استخدم إغلاق لحماية الخصائص داخل كائن من التعديل خارجيًا :

(تقرر في التدريج) ✅

خطأ مطبعي صغير:

أعتقد أنه من المفترض أن يكون "... خارج تعريف bird ." ؟

افهم تعبير الدالة الذي تم استدعاؤه فورًا (IIFE) :

لا توجد مشاكل كبيرة مع هذا التحدي - مجرد اقتراح - بينما أدرك أن النمط المجهول IIFE هو النمط الأكثر شيوعًا (والنمط المستخدم في التحدي التالي) ، ربما هنا مكان جيد لذكر ذلك IIFE يمكن أيضًا تسمية IIFE s.

أفكار؟

استخدم IIFE لإنشاء وحدة نمطية :

أود الحصول على بعض الأفكار حول هذا ... ربما dhcodes أوGreenheart؟
مشكلتي هي أنني لا أعتقد أن التحدي يقوم بعمل مناسب لشرح لماذا IIFE منطقي في هذا السيناريو.

الحل يتطلب:

let funModule = (function() {
  return {
    isCuteMixin: function(obj) {
      obj.isCute = function() {
        return true;
      };
    },  
    singMixin: function(obj) {
      obj.sing = function() {
        console.log("Singing to an awesome tune");
      };
    }
  };
})();

لذلك يمكنك فعل شيء مثل:

function Bird () { }
let duck = new Bird();
funModule.singMixin(duck);
duck.sing();

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

التحدي يقول هذا:

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

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

أي أفكار؟

@ no-stack-dub-sack أوافق على أن هذا ليس أفضل مثال على IIFE. هل من الأفضل أن نقدم module كمثال؟

أعتقد أن القيمة الأساسية لـ IIFE هي أنه يمكنك إنشاء خصائص وأساليب خاصة لكائناتك. إنه مفيد حقًا لتقليل الطرق التي يمكن بها للآخرين (إساءة) استخدام برنامجك على أمل أن يجعل الأمور أكثر موثوقية.

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

يحتوي هذا الموقع على الكثير من الأمثلة الجيدة: https://toddmotto.com/mastering-the-module-pattern/

Greenheart حسنًا في آخر تحديات IIFE هنا ، تم تقديمه كنمط وحدة ، وليس لدي مشكلة في ذلك ، أعتقد أنه يمكن شرحه بشكل أوضح _لماذا_ استخدام IIFE ، وأن IIFE ليس بالضرورة أن يكون موجودًا لتحقيق نفس الوظيفة. وأعتقد أن هذا يقول كل شيء:

القيمة الأساسية لـ IIFE هي أنه يمكنك إنشاء خصائص وأساليب خاصة لكائناتك. إنه مفيد حقًا لتقليل الطرق التي يمكن بها للآخرين (إساءة) استخدام برنامجك على أمل أن يجعل الأمور أكثر موثوقية.

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

التعليمات الحالية تقول:

غالبًا ما يتم استخدام تعبير دالة تم استدعاؤه فورًا (IIFE) لتجميع الوظائف ذات الصلة في كائن أو وحدة واحدة.

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

@ لا مكدس يصف كيس هذا! :يبرز:

أخذت الحرية في تجميعها وإجراء بعض التغييرات الطفيفة. شيء من هذا القبيل هو ما نحتاجه: أحمر الخدود:
An <dfn>immediately invoked function expression</dfn> (IIFE) is often used to group related functionality into a single object or module. While the same functionality can be achieved without an IIFE, its core value in this context is that you can create private properties and methods for your objects. This can be very useful for decreasing the ways others can (mis)use your software, and make things much more reliable.

من المحتمل استخدام <dfn> إذا لم يتم استخدام المصطلح في الاختبارات السابقة.

سأقوم بتحديث الاختبارات الخاصة باستخدام Dot Notation للوصول إلى خصائص كائن !

متابعة https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -275974706.

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

يمكن إصلاح المشكلة الثانية والثالثة عن طريق تغيير البداية لاستخدام الكود الذي اقترحته. يمكن تدريس تعيين كائنات دالة إلى متغيرات إما في مكان آخر أو عن طريق التجربة. أعتقد أننا يجب أن نكون متسقين مع function X () {}

سأصلح هذا: ابتسم:

إصلاح https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276268534: ابتسامة:

إصلاح https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276565338

سأصلح https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276245864

لقد لاحظت أنه لا توجد حلول للتحدي ، لذا فأنا أعمل حاليًا على العلاقات العامة.

فهم الخصائص الخاصة :

(تقرر في التدريج) ✅

تسمح الاختبارات حاليًا باستخدام الطريقة المضمنة Object.keys() ، ولكن أعتقد أن المعسكر يحصلون على تدريب أفضل باستخدام for...in مع Object.hasOwnProperty() .

البرمجة الشيئية: التكرار على جميع الخصائص :

(تقرر في التدريج) ✅

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

function Dog(name) {
  this.name = name;
}

Dog.prototype.numLegs = 4;

let beagle = new Dog("Snoopy");

let ownProps = Object.keys(beagle);
let prototypeProps = Object.keys(Dog.prototype);

إصلاح هذا على الفور: ابتسم:

البرمجة الشيئية: قم بتغيير النموذج الأولي إلى كائن جديد

تعليمات واختبارات غير كافية. هل يجب أن يتواجد describe و eat فقط على prototype ، أم يجب أن يكونا دالات؟

أعتقد أننا يجب أن نضيف اختبارات للتحقق من أنها وظائف.

البرمجة الموجهة للكائنات: تذكر تعيين خاصية المُنشئ عند تغيير النموذج الأولي

تم إرسال العلاقات العامة: white_check_mark:

ربما يجب أن يقوم هذا التحدي بتنسيق "خاصية المُنشئ" كـ <code>constructor</code> property لزيادة سهولة القراءة والاتساق. ما رأيك؟

على سبيل المثال ، تستخدم رسالة الاختبار هذا التنسيق.

اقتراح عام هو أن نستبدل كشوفات الحساب let بـ const لعرض أفضل الممارسات. هذا الفيديو بواسطة mpj يشرح ذلك جيدًا!

البرمجة الشيئية: إعادة تعيين خاصية المُنشئ الموروثة :

تم إرسال PR: white_check_mark:

خطأ إملائي بسيط: من المحتمل أن يكون supertype's supertype 's

البرمجة الشيئية: استخدم IIFE لإنشاء وحدة نمطية :

تم إرسال العلاقات العامة: white_check_mark:

الخطأ المطبعي قاصر: "هنا هو مثال استخدامه:" ينبغي تغييرها إلى "هنا مثال استخدامه:"

أنا أعمل على علاقات عامة لـ https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277447340

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

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

تخلص من CSS المخصص لـ Bootstrap

السبت، 4 فبراير 2017 في 09:11، صموئيل Plumppu [email protected]
كتب:

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

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

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment-277463832 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AX9USApjW3rwocbHWe2yoFLV0RegbkCCks5rZL9SgaJpZM4LxApU
.

iansibindi يبدو أنك مشترك في جميع رسائل هذا المستودع. لتعطيله ، قم بزيارة https://github.com/freecodecamp/freecodecamp وانقر فوق "Unwatch" في الجزء العلوي الأيسر.

آسف للإزعاج!

Greenheart @ أجد أنه من الصعب بعض الشيء متابعة كل من هذه الروابط حتى مع الروابط - أعتقد أنه ربما كان ينبغي أن

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

@ no-stack-dub-sack هاها يجب أن أعترف أنني لا أستطيع متابعته بنفسي أيضًا ، لقد واصلت النشر! :ابتسامة:

سأضيف "PR open" كبير (مع رابط له) إلى بداية كل تعليق قيد العمل قيد العمل / ثابت.

تضمين التغريدة شكر! لقد راجعت أول عدة علاقات عامة

سأصلح https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277457211

سأصلح https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277459744

سأصلح https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277447340

@ no-stack-dub-sack حسنًا ، لا يزال هناك بعض الأشياء التي يجب القيام بها هنا ولكني قمت بحل بعضها اليوم!

عفوًا ، أغلقها مرة أخرى: ضاحكًا:

تضمين التغريدة ارتداد - هل بقي أي شيء لفعله في هذا؟ تم إجراء بعض التحسينات الرئيسية!

@ no-stack-dub-sack لا أعلم - هناك بعض الأشياء المتبقية التي يجب القيام بها وفقًا للتعليقات أعلاه ، ولكن ربما تم حلها في أماكن أخرى؟

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

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