Использование точечной записи для доступа к свойствам объекта

(РАЗРЕШЕНО В ЭТАПЕ) ✅

Эта задача допускает только следующее:

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

Однако мы не заявляем явно, что следует использовать 2 отдельных оператора, и следующее не проходит:

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

Я думаю, мы должны либо указать, что нужно сделать 2 отдельных оператора console.log() , либо провести рефакторинг теста, чтобы принять оба решения - я бы предпочел последний вариант. Мысли?

Проверьте конструктор объекта с помощью instanceof :

(РАЗРЕШЕНО В ЭТАПЕ) ✅

• По какой-то причине линтер выдает предупреждение Expected an assignment of function call and instead saw an expression при написании правильного решения myHouse instanceof House; . Однако вызов действительно проходит.
• Кроме того, сам исходный код имеет предупреждение линтера при загрузке для отсутствующей точки с запятой.
• Наконец, я не уверен, намеренно ли это, но это может немного сбить с толку - в предыдущих задачах этого раздела конструкторы определялись следующим образом:

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'" и проверить его с помощью регулярного выражения.

Используйте наследование, чтобы не повторяться :

Я думаю, что эта задача немного сбивает с толку. Название относится к наследованию, однако наследование никогда не упоминается в задаче - я понимаю, что это связано со следующей задачей, поэтому туристы быстро узнают, но то, как оно представлено, все еще немного отталкивает. Кроме того, в конце испытания мы создали супертип Animal , но нас немного смутило, потому что Animal на этом этапе не привязан к Cat и Dog . Чтобы немного уменьшить путаницу, я думаю, мы могли бы внести небольшое изменение:

Эта фраза восходит к следующему вызову:

Эта и следующая задача будут касаться того, как повторно использовать методы Animal внутри Bird и 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; 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 (так что это, конечно, правильно), источник путаницы исходит отсюда (от Iterate Over All Properties ):

Имея информацию, предоставленную участникам до этого момента, они, вероятно, предположили бы, что для того, чтобы пройти этот тест, им нужно будет определить метод bark непосредственно на экземпляре объекта Dog а не по прототипу.

Различие в том, что для экземпляров Dog , bark _не_ будет свойством own , но _is_ свойством 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 состоит в том, что вы можете создавать частные свойства и методы своих объектов. Это действительно полезно для уменьшения количества способов (неправильного) использования вашего программного обеспечения другими в надежде, что это сделает вещи более надежными.

Например, у вас может быть небольшой служебный модуль для вашего ванильного js-приложения, в котором вы хотите предоставить только несколько общедоступных методов, поскольку остальные будут изменены / удалены и могут вызвать проблемы, если они будут использоваться в других частях кодовой базы.

На этом сайте есть много хороших примеров: https://toddmotto.com/mastering-the-module-pattern/

@Greenheart Что ж, в последней из двух проблем IIFE здесь он представлен как шаблон модуля, и у меня нет проблем с этим, я просто думаю, что это можно было бы более четко объяснить, _ почему_ использовать IIFE, и что IIFE не обязательно должен присутствовать для достижения той же функциональности. Думаю, этим все сказано:

Основная ценность IIFE состоит в том, что вы можете создавать частные свойства и методы своих объектов. Это действительно полезно для уменьшения количества способов (неправильного) использования вашего программного обеспечения другими в надежде, что это сделает вещи более надежными.

Если мы можем просто объяснить это и сообщить пользователю, что «вы можете достичь той же функциональности без IIFE, но с IIFE - лучший способ, и вот почему ...».

Текущие инструкции говорят:

Выражение немедленно вызываемой функции (IIFE) часто используется для группировки связанных функций в один объект или модуль.

К этому давайте просто добавим: «Хотя та же функциональность может быть достигнута без IIFE, основная ценность IIFE в этом контексте состоит в том, что вы можете создавать частные свойства и методы своих объектов. Это может быть очень полезно для уменьшения как другие могут (неправильно) использовать ваше программное обеспечение и сделать его более надежным ".

@ no-stack-dub-sack Это! :указывать:

Я взял на себя смелость скомпилировать его и внести некоторые незначительные изменения. Примерно вот что нам нужно: 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 -275974706.

Первая проблема заключается в том, что линтер не хочет, чтобы мы писали выражение, которое по сути является мертвым кодом (поскольку мы не вызываем функцию и не создаем переменную). Чтобы исправить это, я предлагаю присвоить результат переменной.

Вторую и третью проблему можно решить, изменив начальное значение для использования предложенного вами кода. Назначению функциональных объектов переменным можно научить либо где-нибудь еще, либо на собственном опыте. Я думаю, мы должны придерживаться 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:

Незначительное опечатка: «Вот пример его использования:» должен быть изменен на «Вот пример его использования:»

Я работаю над PR для https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277447340

Еще одно общее предложение: я думаю, нам нужно изменить примеры, чтобы участники лагеря не могли просто скопировать пример и изменить 1-2 вещи, чтобы выполнить задачу.

Примеры должны показывать концепцию, но не использовать свойства или методы, которые используются в задаче itelf. Таким образом, я думаю, люди будут извлекать больше уроков из каждой задачи.

Отказ от пользовательского CSS для Bootstrap

В субботу, 4 февраля 2017 г., в 21:11, Самуэль Пламппу [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 Ха-ха, я должен признать, что я тоже не могу следить за этим, я просто продолжал писать! :улыбка:

Я добавлю большой «PR open» (со ссылкой на него) в начало каждого комментария, который не выполняется / исправлен.

@Greenheart Perfect! Благодаря! Я просмотрел несколько первых 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 Я не знаю - есть еще кое-что, что нужно сделать в соответствии с комментариями выше, но они могли быть решены в других местах?

Я думаю, что это еще не исправлено. Дай мне знать, если ты думаешь иначе

Всем отличная работа. Я закрываю этот вопрос, и мы можем снова открывать более конкретные вопросы по мере их возникновения.