점 표기법을 사용하여 객체 속성에 액세스

(스테이징에서 해결됨) ✅

이 챌린지는 다음 사항만을 해결책으로 받아들입니다.

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

그러나 두 개의 별도 문을 사용해야한다고 명시 적으로 명시하지 않으며 다음은 통과하지 않습니다.

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

2 개의 별도 console.log() 문을 작성해야한다고 지정하거나 두 솔루션을 모두 수용하도록 테스트를 리팩터링해야한다고 생각하고 있습니다. 후자의 옵션을 선호한다고 생각합니다. 생각?

instanceof를 사용하여 객체의 생성자를 확인합니다 .

(스테이징에서 해결됨) ✅

• 어떤 이유로 올바른 솔루션 myHouse instanceof House; 가 작성되면 linter는 경고 Expected an assignment of function call and instead saw an expression 표시합니다. 하지만 도전은 통과합니다.
• 또한 시드 코드 자체에는로드시 세미콜론 누락에 대한 linter 경고가 있습니다.
• 마지막으로, 의도적 인 것인지 확실하지 않지만 약간 혼란 스러울 수 있습니다.이 섹션의 이전 과제에서 생성자는 다음과 같이 정의됩니다.

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

그러나이 도전에서 그들은 다음 구문으로 전환합니다.

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

이것은 혼란의 원인이 될 수있는 문제가 아닙니다. 두 가지 방법을 모두 사용하는 경우 차이점을 구체적으로 확인해야하며 그렇지 않은 경우 섹션 전체에서 구문을 일관되게 유지해야합니다. 아마도 둘 다 소개하는 것이 좋은 생각이라고 생각합니다.

자신의 속성 이해 :

이것에 대한 관찰 일 뿐이고 다른 의견이 무엇인지 궁금합니다.하지만이 도전은 hasOwnProperty 보다 for...in 를 중심으로 진행되는 것 같습니다. 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와 Dog 내부에서 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"

이것은 linter 오류를 발생시킵니다. 대신 다음을 제안합니다.

여기에 매우 사소한 문제-이에 대한 시드의 일부는 다음과 같습니다.

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 : 누군가 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 반환하는 동안 (물론 맞습니다), 혼란의 원인은 여기 ( 모든 속성에 대한 반복 )에서 비롯됩니다.

정보 캠프 참가자가이 시점까지 포기하면 테스트를 통과하기 위해 bark 메서드를 Dog 대신

차이점은 Dog 인스턴스의 경우 bark 는 own 속성이 _not_되지만 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 반환하는 객체를 정의하기 만하면 함수를 전혀 호출하지 않고 덜 장황한 방식으로 동일한 결과를 얻을 수 있습니다.

도전은 다음과 같이 말합니다.

모듈 패턴의 장점은 모든 모션 동작을 단일 객체로 패키징 한 다음 코드의 다른 부분에서 사용할 수 있다는 것입니다.

그러나 이것은 IIFE가 전혀 필요하지 않기 때문에 여기에 개념을 도입하거나 더 강력한 방법을 찾는 아이디어에 의문을 제기 할 것입니다. 캠프 참가자가이를 수행해야한다고 생각할 수 있기 때문에 이것은 혼란 스럽거나 오해의 소지가있을 수 있습니다. 그렇지 않은 경우이 패턴을 달성하십시오.

이견있는 사람?

@ no-stack-dub-sack 이것이 IIFE의 가장 좋은 예가 아니라는 데 동의합니다. 예를 들어 module 를 제공하면 더 좋을까요?

IIFE의 핵심 가치는 개체의 개인 속성과 메서드를 만들 수 있다는 것입니다. 다른 사람들이 당신의 소프트웨어를 더 안정적으로 만들기를 바라면서 당신의 소프트웨어를 잘못 사용할 수있는 방법을 줄이는 데 정말 유용합니다.

예를 들어, 나머지는 변경 / 제거 될 예정이며 코드베이스의 다른 부분에서 사용되면 문제를 일으킬 수 있으므로 몇 가지 공용 메서드 만 노출하려는 vanilla js 애플리케이션 용 작은 유틸리티 모듈이있을 수 있습니다.

이 사이트에는 좋은 예가 많이 있습니다 : https://toddmotto.com/mastering-the-module-pattern/

@Greenheart 여기 2 개의 IIFE 챌린지 중 마지막 챌린지에서 모듈 패턴으로 소개되었으며 문제는 없습니다. _ 왜 _ IIFE를 사용하고 IIFE를 사용하는지 더 명확하게 설명 할 수 있다고 생각합니다. 동일한 기능을 수행하기 위해 반드시 있어야하는 것은 아닙니다. 나는 이것이 모든 것을 말한다고 생각한다.

IIFE의 핵심 가치는 개체의 개인 속성과 메서드를 만들 수 있다는 것입니다. 다른 사람들이 당신의 소프트웨어를 더 안정적으로 만들기를 바라면서 당신의 소프트웨어를 잘못 사용할 수있는 방법을 줄이는 데 정말 유용합니다.

우리가 이것을 설명하고 사용자에게 "IIFE없이 동일한 기능을 얻을 수 있지만 IIFE를 사용하는 것이 더 나은 방법이며, 여기에 이유가 있습니다."라고 알립니다.

현재 지침은 다음과 같습니다.

즉시 호출 된 함수 식 (IIFE)은 관련 기능을 단일 개체 또는 모듈로 그룹화하는 데 자주 사용됩니다.

여기에 다음을 추가해 보겠습니다. "IIFE 없이도 동일한 기능을 달성 할 수 있지만,이 맥락에서 IIFE의 핵심 가치는 객체의 비공개 속성과 메서드를 생성 할 수 있다는 것입니다. 이는 다른 사람들이 귀하의 소프트웨어를 (오용) 사용하여 훨씬 더 안정적으로 만들 수있는 방법. "

@ no-stack-dub-sack 이거! : 포인트 _ 업 :

나는 그것을 자유롭게 컴파일하고 약간의 변경을가했습니다. 이와 같은 것이 우리에게 필요한 것입니다.
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 -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 수정하겠습니다.

나는 도전에 해결책이 없다는 것을 알았 기 때문에 현재 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);

이 문제를 바로 해결합니다.

객체 지향 프로그래밍 : 프로토 타입을 새 객체로 변경

불충분 한 지침 및 테스트. 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-2 가지를 변경할 수 없도록 예제를 변경해야한다고 생각합니다.

예제는 개념을 보여야하지만 챌린지 itelf에서 사용하는 속성이나 메서드를 사용해서는 안됩니다. 이렇게하면 사람들이 각 도전에서 더 많은 것을 배울 것이라고 생각합니다.

부트 스트랩을위한 맞춤 CSS 도랑

2017 년 2 월 4 일 토요일 오후 9시 11 분, Samuel 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를 방문하여 오른쪽 상단의 "Unwatch" 를 클릭하십시오.

불편을 드려 죄송합니다!

@Greenheart 링크로도 이들 각각을 따라가는 것이 조금 어렵다는 것을

PR의 초기 검토를 시작하겠습니다.하지만 PR이 열려있는 경우 원본 댓글 각각에 댓글을 추가하여 해결 된 문제를 추적 할 수 있다고 생각하십니까?

@ no-stack-dub-sack Haha 나도 직접 따라갈 수 없다는 것을 인정해야합니다. :미소:

WIP / 고정 된 각 주석의 시작 부분에 큰 "PR open"(링크 포함)을 추가합니다.

@Greenheart 완벽! 감사! 처음 몇 개의 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 잘 모르겠습니다. 위의 설명에 따라해야 할 일이 몇 가지 있지만 다른 곳에서 해결되었을 수도 있습니다.

아직 고정되지 않은 것 같습니다. 다르게 생각하면 알려주세요

모두 훌륭합니다. 이 문제를 종결하는 중이며 더 구체적인 문제가 발생하면 다시 열 수 있습니다.