Gunakan Notasi Titik untuk Mengakses Properti Objek

(TERSELESAIKAN DALAM STAGING) ✅

Tantangan ini hanya menerima yang berikut sebagai solusi:

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

Namun, kami tidak secara eksplisit menyatakan bahwa 2 pernyataan terpisah harus digunakan, dan berikut ini tidak lolos:

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

Saya berpikir kita harus menentukan bahwa 2 pernyataan terpisah console.log() perlu dibuat, atau refactor pengujian untuk menerima kedua solusi - saya pikir saya lebih suka opsi terakhir. Pikiran?

Verifikasi Pembuat Objek dengan contoh :

(TERSELESAIKAN DALAM STAGING) ✅

• Untuk beberapa alasan, linter menampilkan peringatan Expected an assignment of function call and instead saw an expression ketika solusi yang benar myHouse instanceof House; ditulis. Tantangannya memang berlalu.
• Selain itu, kode benih itu sendiri memiliki peringatan linter saat memuat untuk titik koma yang hilang.
• Terakhir yang satu ini, tidak yakin apakah itu disengaja, tetapi mungkin sedikit membingungkan - dalam tantangan sebelumnya di bagian ini, konstruktor didefinisikan seperti ini:

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

tetapi dalam tantangan ini mereka beralih ke sintaks ini:

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

Ini bukan masalah, melainkan sumber kebingungan yang mungkin. Jika kita menggunakan kedua cara tersebut, saya pikir kita harus secara khusus mencatat perbedaannya, jika tidak, pertahankan agar sintaksnya tetap konsisten di seluruh bagian. Mungkin memperkenalkan keduanya adalah ide yang bagus meskipun saya pikir.

Memahami Properti Sendiri :

Hanya pengamatan yang satu ini, dan penasaran untuk melihat apa pendapat lain - tetapi tantangan ini tampaknya berputar sedikit lebih sekitar for...in daripada hasOwnProperty , dan for...in tidak cukup dijelaskan di bagian ini sampai sekarang.

Jika kita berasumsi bahwa orang-orang telah mengerjakan seluruh kurikulum, saya pikir ini tidak masalah, karena ini setidaknya tercakup dalam bagian Struktur Data Dasar, tetapi jika kita bermaksud agar bagian tersebut tidak bergantung satu sama lain dan tidak memerlukan prasyarat daripada kami mungkin ingin mengunjungi ini lagi?

Pahami Properti Pembuat :

(TERSELESAIKAN DALAM STAGING) ✅

Tantangan ini akan berlalu dengan salah satu solusi:

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

// OR:

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

Saya tidak melihat ini sebagai masalah besar karena naluri menentukan bahwa orang akan mencoba solusi yang disarankan kepada mereka terlebih dahulu, namun, saya juga dapat melihat ini menjadi masalah yang dibuka ketika seorang kemping yang cerdas mencoba dua cara dan ingin melakukannya. tunjukkan ini.

Kami hanya dapat menambahkan kasus uji yang mengatakan "message: 'your solution should use the constructor property'" dan memverifikasi dengan regex.

Gunakan Warisan Agar Anda Tidak Mengulangi Diri Anda :

Tantangan ini menurut saya agak membingungkan. Judulnya mengacu pada Warisan, namun, warisan tidak pernah disebutkan dalam tantangan - saya menyadari itu terkait dengan tantangan berikutnya, jadi berkemah akan segera mengetahuinya, tetapi cara penyajiannya masih agak mengecewakan. Juga, di akhir tantangan, kami telah membuat Animal supertipe, tetapi kami sedikit bingung, karena Animal , pada titik ini, tidak terkait dengan Cat dan Dog . Untuk sedikit meredakan kebingungan, saya pikir kita bisa membuat sedikit perubahan:

Frasa ini berasal dari tantangan berikutnya:

Tantangan ini dan selanjutnya akan membahas bagaimana menggunakan kembali metode Hewan di dalam Burung dan Anjing tanpa mendefinisikannya lagi. Ini menggunakan teknik yang disebut warisan.

Mungkin, untuk mengikat berbagai hal, gambaran tingkat yang lebih tinggi yang mirip dengan ini, sebagai gantinya dapat diberikan dalam tantangan ini yang menghubungkan ketiganya bersama-sama sehingga dipahami bahwa itu adalah urutan, dan benar-benar memperkenalkan konsep yang diberi judul setelah tantangan, dan membuatnya jelas bahwa pada akhir tantangan ini kita belum selesai.

Mewarisi Perilaku dari Supertipe :

(TERSELESAIKAN DALAM STAGING) ✅

Masalah super kecil di sini - bagian dari benih untuk ini berbunyi sebagai berikut:

// Add your code below this line

let duck
let beagle

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

Ini membuat kesalahan linter. Saya akan mengusulkan yang berikut ini:

Masalah super kecil di sini - bagian dari benih untuk ini berbunyi sebagai berikut:

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 - ini semua adalah poin yang bagus, dan saya belum melihat masalah apa pun untuk bagian ini meskipun saya offline sebagian kemarin. Terima kasih telah melalui bagian ini dengan sangat rinci 👍 Berikut adalah pemikiran saya (tl; dr - Saya setuju dengan semua yang Anda kemukakan):

• Use Dot Notation to Access the Properties of an Object : tes harus lulus jika seseorang menggunakan satu pernyataan console.log .
• Verify an Object's Constructor with instanceof : kita harus memperbaiki titik koma yang hilang dan konsisten dengan cara mendefinisikan House . Meskipun ada banyak cara untuk melakukan sesuatu di JS, tidak perlu membingungkan orang yang baru mempelajarinya untuk pertama kali.
• Understanding Own Properties : Mengenai pendapat Anda tentang for...in - kami umumnya berpandangan bahwa tidak masalah menggunakan konsep yang sudah tercakup dalam kurikulum. Para pekemah dapat melompat-lompat sesuka mereka, tetapi topiknya berbeda-beda. (Jika tidak, tantangan bisa menjadi panjang / berulang jika mereka harus membahas kembali hal-hal sebelum membahas intinya). Karena itu, saya pikir mungkin akan membantu untuk memasukkan catatan tepat di bawah contoh yang menjelaskan sintaks secara singkat ("Ingat bahwa for...in tidak ...)
• Understand the Constructor Property : setujui poin Anda untuk ditambahkan menggunakan konstruktor dalam instruksi
• Use Inheritance So You Don't Repeat Yourself : ya, poin bagus untuk mengikat tantangan bersama dengan lebih baik
• Inherit Behaviors from a Supertype : kita harus menambahkan titik koma, dan komentar juga berguna

Beri tahu saya jika Anda ingin mengerjakan ini - saya akan beralih ke bagian lain (dapat mengerjakan ini dalam satu atau dua hari), atau kita dapat membukanya jika perlu bantuan 😄

@HKuz Keren, terima kasih! Saya akan menyelesaikan bagian ini, menambahkan beberapa komentar lagi jika saya punya, dan kemudian kita dapat memutuskan pada saat itu, tetapi saya berpikir membukanya untuk Help Wanted mungkin akan menjadi yang terbaik. Akan terus mengabari Anda.

Tambahkan Metode Setelah Warisan :

Tantangan ini sedikit membingungkan karena kasus uji berikut:

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

Solusi untuk bagian ini mencari ini:

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

dan sementara Dog.prototype.hasOwnProperty('bark') mengembalikan true (jadi ini, tentu saja, benar), sumber kebingungannya berasal dari sini (yaitu dari Iterate Over All Properties ):

Dengan informasi yang diberikan para campers hingga saat ini, mereka kemungkinan besar akan berasumsi bahwa untuk membuat tes tersebut lulus, mereka harus menentukan metode bark , langsung pada instance objek Dog daripada pada prototipe.

Perbedaannya adalah bahwa untuk contoh Dog , bark akan _not_ menjadi properti own , tetapi _adalah properti own dari Dog.prototype . Jadi, ini agak membingungkan bagi seseorang yang baru saja diperkenalkan dengan konsep ini.

Solusi paling sederhana adalah mengubah kasus uji menjadi:

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

Meskipun, mungkin penjelasan singkatnya adalah untuk memberi tahu peserta bahwa properti prototipe prototype sebenarnya adalah properti own dari prototipe itu? Wow, itu adalah pembelit lidah, jadi ya, ini agak membingungkan, dan saya tidak yakin apa cara terbaik untuk menghilangkan kebingungan itu adalah ...

Gunakan Penutupan untuk Melindungi Properti di Dalam Objek agar Tidak Dimodifikasi Secara Eksternal :

(TERSELESAIKAN DALAM STAGING) ✅

Salah ketik kecil:

Saya pikir seharusnya "... di luar definisi bird ." ?

Pahami Ekspresi Fungsi yang Segera Diminta (IIFE) :

Tidak ada masalah besar dengan tantangan ini - hanya saran - sementara saya menyadari IIFE anonim adalah pola yang lebih umum (dan pola yang digunakan dalam tantangan berikutnya), mungkin di sini adalah tempat yang baik untuk menyebutkan IIFE juga dapat diberi nama, dan ini bahkan dapat dianggap sebagai praktik yang lebih baik (meskipun jarang terlihat) karena dapat mempermudah proses debug karena kesalahan akan lebih sulit dilacak jika ada banyak IIFE anonim

Pikiran?

Gunakan IIFE untuk Membuat Modul :

Saya ingin mendapatkan beberapa pemikiran tentang yang satu ini ... mungkin @dhcodes atau @Greenheart?
Masalah saya adalah bahwa menurut saya tantangan tersebut tidak cukup untuk menjelaskan mengapa IIFE masuk akal dalam skenario ini.

Solusinya membutuhkan:

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");
      };
    }
  };
})();

sehingga Anda dapat melakukan sesuatu seperti:

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

namun, Anda bisa mencapai hal yang sama dengan cara yang tidak terlalu bertele-tele, dan tanpa memanggil fungsi sama sekali, cukup dengan mendefinisikan objek yang dikembalikan IIFE .

Tantangannya mengatakan ini:

Keuntungan dari pola modul adalah bahwa semua perilaku gerakan dapat dikemas menjadi satu objek yang kemudian dapat digunakan oleh bagian lain dari kode Anda.

Tapi karena ini tidak memerlukan IIFE sama sekali, saya kira saya akan mempertanyakan gagasan untuk memperkenalkan konsep di sini, atau menemukan cara yang lebih kuat untuk mengaitkannya. Ini mungkin membingungkan / menyesatkan karena pekemah mungkin berpikir mereka PERLU melakukan ini untuk mencapai pola ini jika bukan itu masalahnya.

Ada pemikiran?

@ no-stack-dub-sack Saya setuju bahwa ini bukan contoh terbaik dari sebuah IIFE. Apakah lebih baik jika kami memberikan module sebagai contoh?

Saya pikir nilai inti dari IIFE adalah Anda dapat membuat properti pribadi dan metode objek Anda. Ini sangat berguna untuk mengurangi cara orang lain dapat (salah) menggunakan perangkat lunak Anda dengan harapan hal itu membuat segalanya lebih dapat diandalkan.

Misalnya, Anda mungkin memiliki modul utilitas kecil untuk aplikasi vanilla js di mana Anda hanya ingin mengekspos beberapa metode publik karena metode lainnya akan segera diubah / dihapus dan akan menyebabkan masalah jika digunakan di bagian lain dari basis kode.

Situs ini memiliki banyak contoh bagus: https://toddmotto.com/mastering-the-module-pattern/

@Greenheart Nah di bagian terakhir dari 2 tantangan IIFE di sini, ini diperkenalkan sebagai pola modul, dan saya tidak memiliki masalah dengan itu, saya hanya berpikir itu bisa dijelaskan lebih jelas _why_ menggunakan IIFE, dan itu IIFE tidak harus hadir untuk mencapai fungsi yang sama. Saya pikir ini menjelaskan semuanya:

nilai inti dari IIFE adalah Anda dapat membuat properti pribadi dan metode objek Anda. Ini sangat berguna untuk mengurangi cara orang lain dapat (salah) menggunakan perangkat lunak Anda dengan harapan hal itu membuat segalanya lebih dapat diandalkan.

Jika kami hanya dapat menjelaskan hal ini, dan memberi tahu pengguna "Anda dapat mencapai fungsionalitas yang sama tanpa IIFE, tetapi dengan IIFE adalah cara yang lebih baik, dan inilah alasannya ...".

Instruksi saat ini mengatakan:

Ekspresi fungsi yang segera dipanggil (IIFE) sering digunakan untuk mengelompokkan fungsionalitas terkait ke dalam satu objek atau modul.

Untuk ini, mari tambahkan saja: "Meskipun fungsionalitas yang sama dapat dicapai tanpa IIFE, nilai inti IIFE, dalam konteks ini, adalah Anda dapat membuat properti pribadi dan metode objek. Ini bisa sangat berguna untuk mengurangi cara orang lain dapat (salah) menggunakan perangkat lunak Anda dan membuat segalanya lebih dapat diandalkan. "

@ no-stack-dub-sack Ini! : point_up:

Saya mengambil kebebasan untuk menyusunnya dan membuat beberapa perubahan kecil. Sesuatu seperti inilah yang kita butuhkan: blush on:
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.

Mungkin menggunakan <dfn> jika istilah tersebut belum digunakan dalam tantangan sebelumnya.

Saya akan melanjutkan dan memperbarui tes untuk Gunakan Notasi Titik untuk Mengakses Properti Objek !

Melanjutkan dengan https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -275974706.

Masalah pertama adalah karena linter tidak ingin kita menulis ekspresi yang pada dasarnya adalah kode mati (karena kita tidak memanggil fungsi atau membuat variabel). Untuk memperbaikinya, saya sarankan kita menetapkan hasilnya ke variabel.

Masalah kedua dan ketiga dapat diperbaiki dengan mengubah seed untuk menggunakan kode yang Anda usulkan. Menetapkan objek fungsi ke variabel bisa diajarkan baik di tempat lain, atau dengan pengalaman. Saya pikir kita harus konsisten dengan function X () {}

Saya akan memperbaiki ini: senyum:

Memperbaiki https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276268534: smile:

Memperbaiki https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276565338

Saya akan memperbaiki https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276245864

Saya perhatikan bahwa tidak ada tantangan yang memiliki solusi, jadi saya saat ini sedang mengerjakan PR.

Memahami Properti Sendiri :

(TERSELESAIKAN DALAM STAGING) ✅

Tes saat ini memungkinkan penggunaan metode bawaan Object.keys() , tetapi saya pikir para berkemah mendapatkan latihan yang lebih baik dengan menggunakan for...in dikombinasikan dengan Object.hasOwnProperty() .

Pemrograman Berorientasi Objek: Iterasi Pada Semua Properti :

(TERSELESAIKAN DALAM STAGING) ✅

Baru saja mengetahui bahwa tantangan ini memiliki masalah yang sama - ini memungkinkan penggunaan Object.keys() Karena saya masih tidak berpikir ini harus diizinkan dalam tantangan ini, saya akan membuat PR menambahkan kasus uji dari baris ini

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);

Segera perbaiki ini: senyum:

Pemrograman Berorientasi Objek: Ubah Prototipe menjadi Objek Baru

Instruksi dan tes yang tidak memadai. Haruskah describe dan eat hanya ada di prototype , atau haruskah mereka berfungsi?

Saya pikir kita harus menambahkan tes untuk memverifikasi bahwa mereka berfungsi.

Pemrograman Berorientasi Objek: Ingatlah untuk Mengatur Properti Konstruktor saat Mengubah Prototipe

PR dikirim: white_check_mark:

Tantangan ini mungkin harus memformat "properti konstruktor" sebagai <code>constructor</code> property untuk meningkatkan keterbacaan dan konsistensi. Bagaimana menurut anda?

Misalnya, pesan pengujian menggunakan format ini.

Saran umumnya adalah kita mengganti pernyataan let dengan const untuk menunjukkan praktik terbaik. Video oleh @mpj ini menjelaskannya dengan baik!

Pemrograman Berorientasi Objek: Setel Ulang Properti Konstruktor yang Diwarisi :

PR Dikirim: white_check_mark:

Kesalahan kecil: supertype's mungkin seharusnya supertype

Pemrograman Berorientasi Objek: Gunakan IIFE untuk Membuat Modul :

PR dikirim: white_check_mark:

Minor typo: "Berikut ini adalah contoh sebuah menggunakannya:" harus diubah menjadi "Berikut adalah contoh menggunakannya:"

Saya sedang mengerjakan PR untuk https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277447340

Saran umum lainnya: Saya pikir kita perlu mengubah contoh sehingga pekemah tidak bisa hanya menyalin contoh dan mengubah 1-2 hal untuk menyelesaikan tantangan.

Contoh harus menunjukkan konsep, tetapi tidak menggunakan properti atau metode yang digunakan oleh tantangan itu sendiri. Dengan cara ini, saya pikir orang akan belajar lebih banyak dari setiap tantangan.

Singkirkan CSS Kustom untuk Bootstrap

Pada hari Sabtu, 4 Feb 2017 jam 21:11, Samuel Plumppu [email protected]
menulis:

Saran umum lainnya: Saya pikir kita perlu mengubah contoh jadi
berkemah tidak bisa begitu saja menyalin contoh dan mengubah 1-2 hal untuk menyelesaikan
tantangan.

Contoh harus menunjukkan konsep, tetapi tidak menggunakan properti atau metode
yang digunakan oleh tantangan itu sendiri. Dengan cara ini, saya pikir orang akan belajar
lebih dari setiap tantangan.

-
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment-277463832 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AX9USApjW3rwocbHWe2yoFLV0RegbkCCks5rZL9SgaJpZM4LxApU
.

@iansibindi Sepertinya Anda telah berlangganan semua pesan dari gudang ini. Untuk menonaktifkannya, kunjungi https://github.com/freecodecamp/freecodecamp dan klik "Unwatch" di kanan atas.

Maaf untuk ketidaknyamanannya!

@Greenheart Saya merasa agak sulit untuk mengikuti masing-masing ini bahkan dengan

Saya akan mulai melakukan tinjauan awal terhadap PR, tetapi apakah menurut Anda Anda dapat menambahkan komentar ke setiap komentar asli jika mereka memiliki PR yang terbuka untuk mereka sehingga kami dapat melacak masalah mana yang telah ditangani?

@ no-stack-dub-sack Haha Saya harus mengakui bahwa saya juga tidak dapat mengikutinya, saya terus memposting! :tersenyum:

Saya akan menambahkan "PR terbuka" besar (dengan tautan ke sana) ke awal setiap komentar yaitu WIP / tetap.

@Green Sempurna! Terima kasih! Saya telah meninjau beberapa PR pertama

Saya akan memperbaiki https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277457211

Saya akan memperbaiki https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277459744

Saya akan memperbaiki https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277447340

@ no-stack-dub-sack Baiklah, masih ada beberapa hal yang harus dilakukan di sini tapi saya menyelesaikan beberapa di antaranya hari ini!

Ups, tutup lagi: tertawa:

@Greenart Whoa! Sebuah kemunduran - apakah ada yang tersisa untuk dilakukan dalam hal ini? Beberapa perbaikan besar telah dilakukan!

@ no-stack-dub-sack Saya tidak tahu - ada beberapa hal yang harus dilakukan menurut komentar di atas, tetapi mungkin telah diselesaikan di tempat lain?

Saya pikir ini belum diperbaiki. Beri tahu saya jika Anda berpikir sebaliknya

Kerja bagus semuanya. Saya menutup masalah ini dan kami dapat membuka kembali masalah yang lebih spesifik saat muncul.