ドット表記を使用してオブジェクトのプロパティにアクセスする

（ステージングで解決）✅

この課題は、解決策として以下のみを受け入れます。

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

ただし、2つの別個のステートメントを使用する必要があることを明示的に述べておらず、以下は合格しません。

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

2つの別々のconsole.log()ステートメントを作成する必要があることを指定するか、両方のソリューションを受け入れるようにテストをリファクタリングする必要があると考えています。後者のオプションをお勧めします。 考え？

instanceof ：を使用

（ステージングで解決）✅

• 何らかの理由で、正しいソリューションmyHouse instanceof House;が書き込まれると、リンターは警告Expected an assignment of function call and instead saw an expressionスローします。 しかし、挑戦は通過します。
• また、シードコード自体には、セミコロンがない場合のロード時にリンター警告があります。
• 最後に、これは意図的なものかどうかはわかりませんが、少し混乱する可能性があります。このセクションの以前の課題では、コンストラクターは次のように定義されています。

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

しかし、このチャレンジでは、次の構文に切り替えます。

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

これは、混乱の原因となる可能性があるほどの問題ではありません。 両方の方法を使用する場合は、違いに特に注意する必要があると思います。それ以外の場合は、セクション全体で構文の一貫性を保つだけです。 おそらく両方を導入するのは良い考えだと思いますが。

自分の特性を理解する：

ちょうどこの1の観察、およびその他の意見が何であるかを見るために好奇心-しかし、この課題は、より多くの周りのビットを公転しているようだ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'"というテストケースを追加して、正規表現で検証するだけです。

継承を使用して、自分自身を繰り返さないようにします。

この課題は少し紛らわしいと思います。 タイトルは継承を指しますが、継承はチャレンジで言及されることはありません-継承は次のチャレンジに関連していることを認識しているので、キャンパーはすぐにわかりますが、その提示方法はまだ少し不快です。 また、チャレンジの最後にAnimalスーパータイプを作成しましたが、現時点ではAnimalがCat関連付けられていないため、少し混乱しています。 Dog 。 混乱を少し和らげるために、少し変更を加えることができると思います。

このフレーズは次の挑戦から来ています：

この課題と次の課題では、Bird andDog内でAnimalのメソッドを再定義せずに再利用する方法について説明します。 継承と呼ばれる手法を使用します。

おそらく、物事を結び付けるために、これに似たより高いレベルの概要を、代わりにこのチャレンジで与えることができます。このチャレンジでは、3つすべてを結び付けて、それらがシーケンスであることが理解され、実際にチャレンジのタイトルの後に付けられた概念を導入して、このチャレンジの終わりには、まだ完了していないことを明確にします。

スーパータイプから動作を継承する：

（ステージングで解決）✅

ここでの超マイナーな問題-このシードの一部は次のようになります。

// 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; dr-あなたが提起したすべてに同意します）：

• Use Dot Notation to Access the Properties of an Object ：誰かが1つの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 ：必ずセミコロンを追加する必要があり、コメントも役立ちます

これらに取り組みたいかどうか教えてください-私は別のセクションにジャンプしています（1日か2日でこれに取り組むことができます）、または助けが必要なときにこれを開くことができます😄

@HKuzかっこいい、ありがとう！ セクションを終了し、コメントがあればさらにいくつか追加して、その時点で決定できますが、HelpWantedに公開するのが最善だと思います。 投稿を続けます。

継承後にメソッドを追加する：

次のテストケースがあるため、この課題は少し混乱します。

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からです）：

キャンピングカーはこの時点まで情報を提供されているため、そのテストに合格するには、 Dogではなくbarkメソッドを定義する必要があると想定する可能性があります。プロトタイプで。

違いは、 Dogインスタンスの場合、 barkはownプロパティではないが、 Dog.prototype ownプロパティであるということです。 Dog.prototype 。 したがって、これは、これらの概念を紹介されたばかりの人にとっては少し混乱します。

最も簡単な解決策は、テストケースを次のように変更することです。

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

とはいえ、簡単な説明は、プロトタイプのprototypeプロパティが実際にはそのプロトタイプのownプロパティであることをキャンパーに知らせるためですか？ うわー、それは早口言葉なので、ええ、それは少し混乱しています、そして私はその混乱を和らげるための最良の方法が何であるかわかりません...

クロージャを使用して、オブジェクト内のプロパティが外部から変更されないように保護します。

（ステージングで解決）✅

小さなタイプミス：

「... birdの定義外」だと思います。 ？

即時呼び出し関数式（IIFE）を理解する：

このチャレンジには大きな問題はありません-単なる提案です-匿名のIIFEがより一般的なパターン（および次のチャレンジで使用されるパターン）であることに気付きましたが、おそらくここでIIFEも名前を付けることができます。匿名のIIFEが多いとエラーを追跡するのが難しくなるため、デバッグが容易になるため、これは（あまり一般的ではありませんが）より良い方法と見なされることもあります。

考え？

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が返すオブジェクトを定義するだけで、関数をまったく呼び出さずに、より冗長でない方法で同じことを実現できます。

チャレンジはこれを言います：

モジュールパターンの利点は、すべてのモーション動作を1つのオブジェクトにパッケージ化して、コードの他の部分で使用できることです。

しかし、これはIIFEをまったく必要としないので、ここで概念を導入するか、それを結び付けるためのより強力な方法を見つけるという考えに疑問を呈するでしょう。キャンピングカーはこれを行う必要があると考える可能性があるため、これは混乱/誤解を招く可能性がありますそうでない場合は、このパターンを達成してください。

何かご意見は？

@ no-stack-dub-sackこれがIIFEの最良の例ではないことに同意します。 例としてmoduleを提供するとよいでしょうか？

IIFEのコアバリューは、オブジェクトのプライベートプロパティとメソッドを作成できることだと思います。 それが物事の信頼性を高めることを期待して、他の人があなたのソフトウェアを（誤）使用する方法を減らすのに本当に役立ちます。

たとえば、バニラjsアプリケーション用の小さなユーティリティモジュールがあり、残りは変更/削除されようとしているため、いくつかのパブリックメソッドのみを公開し、コードベースの他の部分で使用すると問題が発生する可能性があります。

このサイトには多くの良い例があります： https ：

@Greenheartここでの2つのIIFEチャレンジの最後では、モジュールパターンとして導入されていますが、問題はありません。IIFEを使用する理由とIIFEをより明確に説明できると思います。同じ機能を実現するために、必ずしも存在する必要はありません。 私はこれがすべてを言っていると思います：

IIFEのコアバリューは、オブジェクトのプライベートプロパティとメソッドを作成できることです。 それが物事の信頼性を高めることを期待して、他の人があなたのソフトウェアを（誤）使用する方法を減らすのに本当に役立ちます。

これを説明して、「IIFEがなくても同じ機能を実現できますが、IIFEを使用する方が良い方法であり、その理由は...」とユーザーに知らせることができれば。

現在の指示は言う：

即時呼び出し関数式（IIFE）は、関連する機能を単一のオブジェクトまたはモジュールにグループ化するためによく使用されます。

これに次のように追加しましょう。「IIFEがなくても同じ機能を実現できますが、このコンテキストでのIIFEのコアバリューは、オブジェクトのプライベートプロパティとメソッドを作成できることです。これは、オブジェクトのプライベートプロパティとメソッドを減らすのに非常に役立ちます。他の人があなたのソフトウェアを（誤）使用して、物事をはるかに信頼できるものにする方法。」

@ no-stack-dub-sackこれ！ ：point_up：

私はそれをコンパイルしていくつかの小さな変更を加える自由を取りました。 このようなものが必要です：blush：
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>使用する可能性があります。

先に進み、ドット表記を使用してオブジェクトのプロパティにアクセスするためのテストを更新

https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment-257974706を続行し

最初の問題は、リンターが本質的にデッドコードである式を記述したくないためです（関数を呼び出したり変数を作成したりしないため）。 これを修正するには、結果を変数に割り当てることをお勧めします。

2番目と3番目の問題は、提案したコードを使用するようにシードを変更することで修正できます。 関数オブジェクトを変数に割り当てることは、どこか別の場所で、または経験によって教えることができます。 function X () {}と一貫している必要があると思います

私はこれを修正します：smile：

https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276268534：smile：の修正

https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment-276565338の修正

https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment-276245864を修正し

課題に解決策がないことに気づいたので、現在PRに取り組んでいます。

自分の特性を理解する：

（ステージングで解決）✅

テストでは現在、組み込みメソッドObject.keys()使用が許可されていますが、キャンピングカーはfor...inをObject.hasOwnProperty()と組み合わせて使用​​することでより良い練習ができると思います。

オブジェクト指向プログラミング：すべてのプロパティを反復処理します：

（ステージングで解決）✅

このチャレンジにも同じ問題があることがObject.keys()使用できます。これらのチャレンジではまだ許可されるべきではないと思うので、この行からテストケースを追加してPRを作成します。

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

これをすぐに修正する：smile：

オブジェクト指向プログラミング：プロトタイプを新しいオブジェクトに変更します

不十分な指示とテスト。 describeとeatはprototypeに存在する必要がありますか、それとも関数である必要がありますか？

関数であることを確認するためのテストを追加する必要があると思います。

オブジェクト指向プログラミング：プロトタイプを変更するときは、コンストラクタープロパティを設定することを忘れないでください

提出されたPR：white_check_mark：

この課題では、読みやすさと一貫性を高めるために、おそらく「コンストラクタープロパティ」を<code>constructor</code> propertyとしてフォーマットする必要があります。 どう思いますか？

たとえば、テストメッセージはこの形式を使用します。

一般的な提案は、ベストプラクティスを示すために、 letステートメントをconstに置き換えることです。 @mpjによるこのビデオはそれをよく説明しています！

オブジェクト指向プログラミング：継承されたコンストラクタープロパティをリセットします：

提出されたPR：white_check_mark：

マイナーなタイプミス： supertype'sはおそらくsupertypeのはずです

オブジェクト指向プログラミング：IIFEを使用してモジュールを作成します。

提出されたPR：white_check_mark：

マイナータイプミス：「ここにそれを使用した例です。」に変更する必要があります「ここでは、それを使用した例です。」

https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment-277447340のPRに取り組んでい

もう1つの一般的な提案：キャンピングカーが例をコピーして1〜2個変更してチャレンジを完了することができないように、例を変更する必要があると思います。

例は概念を示す必要がありますが、チャレンジitelfで使用されるプロパティやメソッドは使用しないでください。 このように、人々はそれぞれの挑戦からより多くを学ぶと思います。

ブートストラップ用のカスタムCSSを捨てる

午前9時11分PMに土、2017年2月4日には、サミュエルPlumppu [email protected]
書きました：

別の一般的な提案：例を変更する必要があると思います
キャンピングカーは、例をコピーして1〜2個変更して、
チャレンジ。

例は概念を示す必要がありますが、プロパティやメソッドは使用しないでください
チャレンジitelfによって使用されます。 このように、私は人々が学ぶと思います
各チャレンジからより多く。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment-277463832 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AX9USApjW3rwocbHWe2yoFLV0RegbkCCks5rZL9SgaJpZM4LxApU
。

@iansibindiこのリポジトリのすべてのメッセージを購読しているようです。 無効にするには、 https：//github.com/freecodecamp/freecodecampにアクセスし、右上の[

ご不便おかけしてすみません！

@Greenheartリンクがあっても、これらのそれぞれをたどるのは少し難しいと

PRの最初のレビューを開始しますが、PRが開いている場合は、元のコメントのそれぞれにコメントを追加して、どの問題が解決されたかを追跡できると思いますか？

@ no-stack-dub-sackははは、自分でもフォローできないことを認めざるを得ません。投稿を続けました。 ：スマイル：

WIP /修正済みの各コメントの先頭に、大きな「PRオープン」（リンク付き）を追加します。

@グリーンハートパーフェクト！ ありがとう！ 最初のいくつかのPRを確認しました

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さて、ここでやるべきことはまだいくつかありますが、今日はそれらのいくつかを解決しました！

おっと、また閉じました：笑い：

@Greenheartおっ！ 先祖返り-これでやるべきことは残っていますか？ いくつかの大きな改善が行われました！

@ no-stack-dub-sackわかりません-上記のコメントによると、やるべきことがいくつか残っていますが、他の場所で解決された可能性がありますか？

まだ修正されていないと思います。 あなたがそうでないと思うなら私に知らせてください

みなさん、お疲れ様でした。 私はこの問題を閉じており、問題が発生したら、より具体的な問題を再開できます。