Utiliser la notation par points pour accéder aux propriétés d'un objet

(RÉSOLU EN STAGING) ✅

Ce défi n'accepte que les éléments suivants comme solution:

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

Cependant, nous n'indiquons pas explicitement que 2 instructions distinctes doivent être utilisées, et ce qui suit ne passe pas:

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

Je pense que nous devrions soit spécifier que 2 déclarations distinctes console.log() doivent être faites, soit refactoriser le test pour accepter les deux solutions - je pense que je préférerais la dernière option. Pensées?

Vérifiez le constructeur d'un objet avec instanceof :

(RÉSOLU EN STAGING) ✅

• Pour une raison quelconque, le linter lance l'avertissement Expected an assignment of function call and instead saw an expression lorsque la solution correcte myHouse instanceof House; est écrite. Le défi passe cependant.
• En outre, le code de départ lui-même a un avertissement linter lors du chargement pour un point-virgule manquant.
• Enfin sur celui-ci, je ne sais pas si c'est intentionnel, mais cela peut être un peu déroutant - dans les défis précédents de cette section, les constructeurs sont définis comme ceci:

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

mais dans ce défi, ils passent à cette syntaxe:

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

Ce n'est pas tant un problème qu'une source possible de confusion. Si nous utilisons les deux méthodes, je pense que nous devrions spécifiquement noter la différence, sinon, gardez simplement la syntaxe cohérente tout au long de la section. Je pense que l'introduction des deux est probablement une bonne idée.

Comprendre ses propres propriétés :

Juste une observation sur celui-ci, et curieux de voir quelles sont les autres opinions - mais ce défi semble tourner un peu plus autour de for...in plutôt que de hasOwnProperty , et for...in ne l'est pas correctement expliqué dans cette section pour le moment.

Si nous supposons que les gens ont travaillé sur le reste du programme, je pense que c'est OK, car cela est au moins couvert dans la section Structures de données de base, mais si nous voulons que les sections soient indépendantes les unes des autres et n'exigent pas de prérequis que nous voudrons peut-être revoir cela?

Comprendre la propriété du constructeur :

(RÉSOLU EN STAGING) ✅

Ce défi passera avec l'une ou l'autre des solutions:

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

// OR:

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

Je ne vois pas cela comme un problème majeur car l'instinct dicte que les gens essaieront d'abord la solution qui leur est suggérée, cependant, je peux également voir que c'est un problème qui se pose sur toute la ligne lorsqu'un campeur averti essaie dans les deux sens et veut faites remarquer cela.

Nous pourrions simplement ajouter un cas de test qui dit "message: 'your solution should use the constructor property'" et vérifier avec une regex.

Utilisez l'héritage pour ne pas vous répéter :

Ce défi, je pense, est un peu déroutant. Le titre fait référence à l'héritage, cependant, l'héritage n'est jamais mentionné dans le défi - je me rends compte qu'il est lié au prochain défi, donc les campeurs le découvriront rapidement, mais la façon dont il est présenté est encore un peu déconcertant. De plus, à la fin du défi, nous avons créé un supertype Animal , mais nous sommes un peu confus, car Animal , à ce stade, ne correspond pas à Cat et Dog . Pour apaiser un peu la confusion, je pense que nous pourrions faire un léger changement:

Cette phrase vient du prochain défi:

Ce défi et le prochain couvriront comment réutiliser les méthodes d'Animal dans Bird and Dog sans les redéfinir. Il utilise une technique appelée héritage.

Peut-être, pour relier les choses, un aperçu de plus haut niveau similaire à celui-ci peut être donné à la place dans ce défi qui lie les 3 ensemble afin qu'il soit compris qu'il s'agit d'une séquence, et introduit en fait le concept que le défi est intitulé clairement qu'à la fin de ce défi, nous n'avons pas encore terminé.

Hériter des comportements d'un supertype :

(RÉSOLU EN STAGING) ✅

Problème super mineur ici - une partie de la graine pour cela se lit comme suit:

// Add your code below this line

let duck
let beagle

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

Cela génère une erreur de linter. Je proposerais plutôt ce qui suit:

Problème super mineur ici - une partie de la graine pour cela se lit comme suit:

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 - ce sont tous d'excellents points, et je n'ai vu aucun problème pour cette section bien que j'étais hors ligne une partie d'hier. Merci d'avoir parcouru cette section avec autant de détails 👍 Voici mes pensées (tl; dr - je suis d'accord avec tout ce que vous avez soulevé):

• Use Dot Notation to Access the Properties of an Object : les tests doivent réussir si quelqu'un utilise une instruction console.log .
• Verify an Object's Constructor with instanceof : nous devons corriger le point-virgule manquant et être cohérent sur la façon dont House est défini. Bien qu'il existe plusieurs façons de faire les choses dans JS, inutile de confondre les gens qui apprennent cela pour la première fois.
• Understanding Own Properties : À propos de votre point sur le for...in - nous avons généralement considéré qu'il était acceptable d'utiliser des concepts déjà couverts dans le programme. Les campeurs peuvent sauter comme ils le souhaitent, mais il y a un flux vers les sujets. (Sinon, les défis peuvent devenir longs / répétitifs s'ils doivent recouvrir les choses avant d'en arriver au but). Cela dit, je pense qu'il peut être utile de mettre une note juste sous l'exemple qui explique brièvement la syntaxe ("Rappelez-vous que for...in fait ...)
• Understand the Constructor Property : convenez de votre point à ajouter en utilisant le constructeur dans les instructions
• Use Inheritance So You Don't Repeat Yourself : oui, de bons points pour mieux relier les défis
• Inherit Behaviors from a Supertype : nous devrions certainement ajouter les points-virgules, et les commentaires sont également utiles

Faites-moi savoir si vous voulez travailler sur ceux-ci - je saute dans une autre section (je pourrais y travailler dans un jour ou deux), ou nous pourrions ouvrir cela comme de l'aide

@HKuz Cool, merci! Je vais terminer la section, ajouter quelques commentaires supplémentaires si j'en ai, puis nous pourrons décider à ce stade, mais je pense que l'ouvrir à Help Wanted sera probablement mieux. Vous tiendrons au courant.

Ajouter des méthodes après l'héritage :

Ce défi est légèrement déroutant en raison du cas de test suivant:

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

La solution pour cette partie est à la recherche de ceci:

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

et alors que Dog.prototype.hasOwnProperty('bark') renvoie true (donc c'est bien sûr correct), la source de la confusion vient d'ici (qui provient de Iterate Over All Properties ):

Avec les informations données aux campeurs jusqu'à présent, ils supposeraient probablement que pour réussir ce test, ils devraient définir la méthode bark , directement sur l'instance d'objet de Dog plutôt que sur le prototype.

La distinction est que pour les instances de Dog , bark ne serait _pas_ une propriété own , mais qu'elle _est_ une propriété own de Dog.prototype . Donc, c'est un peu déroutant pour quelqu'un qui vient de se familiariser avec ces concepts.

La solution la plus simple serait de changer le cas de test pour dire:

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

Cependant, une explication rapide est peut-être pour faire savoir aux campeurs qu'une propriété prototype d'un prototype est en fait une propriété own de ce prototype? Wow, c'est un virelangue, alors oui, c'est un peu déroutant, et je ne sais pas quelle est la meilleure façon de dissiper cette confusion ...

Utilisez la fermeture pour protéger les propriétés d'un objet contre toute modification externe :

(RÉSOLU EN STAGING) ✅

Petite faute de frappe:

Je pense que censé être "... en dehors de la définition de bird ". ?

Comprendre l'expression de fonction immédiatement appelée (IIFE) :

Pas de problème majeur avec ce défi - juste une suggestion - alors que je réalise que les IIFE anonymes sont le modèle le plus courant (et le modèle utilisé dans le prochain défi), voici peut-être un bon endroit pour mentionner que IIFE peuvent également être nommés, et cela pourrait même être considéré comme une meilleure pratique (bien que moins fréquemment observée) car cela peut faciliter le débogage car les erreurs seront plus difficiles à détecter s'il y a beaucoup de IIFE anonymes

Pensées?

Utilisez un IIFE pour créer un module :

J'aimerais avoir quelques réflexions sur celui-ci ... peut-être @dhcodes ou @Greenheart?
Mon problème est que je ne pense pas que le défi explique suffisamment pourquoi un IIFE sens dans ce scénario.

La solution nécessite:

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

afin que vous puissiez faire quelque chose comme:

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

cependant, vous pouvez réaliser la même chose d'une manière moins verbeuse et sans invoquer de fonction du tout, simplement en définissant simplement l'objet que IIFE retourne.

Le défi dit ceci:

L'avantage du modèle de module est que tous les comportements de mouvement peuvent être regroupés dans un seul objet qui peut ensuite être utilisé par d'autres parties de votre code.

Mais comme cela ne nécessite pas du tout une IIFE, je suppose que je remettrais en question l'idée d'introduire le concept ici, ou de trouver un moyen plus solide de le lier. Cela pourrait être déroutant / trompeur car les campeurs pourraient penser qu'ils DOIVENT le faire pour réaliser ce modèle quand ce n'est pas le cas.

Des pensées?

@ no-stack-dub-sack Je suis d'accord que ce n'est pas le meilleur exemple d'un IIFE. Serait-il préférable de fournir un module comme exemple?

Je pense que la valeur fondamentale de l'IIFE est que vous pouvez créer des propriétés privées et des méthodes de vos objets. C'est vraiment utile pour réduire les façons dont les autres peuvent (mal) utiliser votre logiciel dans l'espoir que cela rend les choses plus fiables.

Par exemple, vous pourriez avoir un petit module utilitaire pour votre application vanilla js où vous ne voulez exposer que quelques méthodes publiques puisque les autres sont sur le point d'être modifiées / supprimées et causeraient des problèmes si elles étaient utilisées dans d'autres parties de la base de code.

Ce site a beaucoup de bons exemples: https://toddmotto.com/mastering-the-module-pattern/

@Greenheart Eh bien dans le dernier des 2 défis IIFE ici, il est présenté comme un modèle de module, et je n'ai pas de problème avec cela, je pense juste que cela pourrait être expliqué plus clairement _pourquoi_ utiliser un IIFE, et qu'un IIFE ne doit pas nécessairement être présent pour obtenir la même fonctionnalité. Je pense que cela dit tout:

La valeur fondamentale de l'IIFE est que vous pouvez créer des propriétés privées et des méthodes de vos objets. C'est vraiment utile pour réduire les façons dont les autres peuvent (mal) utiliser votre logiciel dans l'espoir que cela rend les choses plus fiables.

Si nous pouvons simplement expliquer cela, et faire savoir à l'utilisateur "vous pouvez obtenir la même fonctionnalité sans un IIFE, mais avec un IIFE est une meilleure façon, et voici pourquoi ...".

Les instructions actuelles disent:

Une expression de fonction immédiatement invoquée (IIFE) est souvent utilisée pour regrouper les fonctionnalités associées en un seul objet ou module.

À cela, ajoutons simplement: «Bien que la même fonctionnalité puisse être obtenue sans un IIFE, la valeur fondamentale de l’IIFE, dans ce contexte, est que vous pouvez créer des propriétés privées et des méthodes de vos objets. Cela peut être très utile pour réduire le comment les autres peuvent (mal) utiliser votre logiciel et rendre les choses beaucoup plus fiables. "

@ no-stack-dub-sack Ceci! :pointer vers le haut:

J'ai pris la liberté de le compiler et d'apporter quelques modifications mineures. Quelque chose comme ça est ce dont nous avons besoin: rougir:
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.

Utilisez éventuellement <dfn> si le terme n'a pas été utilisé dans les défis précédents.

Je vais continuer et mettre à jour les tests pour utiliser la notation par points pour accéder aux propriétés d'un objet !

Poursuivant avec https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -275974706.

Le premier problème est que le linter ne veut pas que nous écrivions une expression qui est essentiellement du code mort (puisque nous n'appelons pas de fonction ou ne créons pas de variable). Pour résoudre ce problème, je suggère que nous attribuions le résultat à une variable.

Le deuxième et le troisième problème peuvent être résolus en modifiant la valeur de départ pour utiliser le code que vous avez proposé. L'affectation d'objets de fonction à des variables peut être enseignée ailleurs ou par expérience. Je pense que nous devrions être cohérents avec function X () {}

Je vais réparer ça: sourire:

Correction de https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276268534: sourire:

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

Je vais réparer https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276245864

J'ai remarqué qu'aucun défi n'avait de solutions, donc je travaille actuellement sur un PR.

Comprendre ses propres propriétés :

(RÉSOLU EN STAGING) ✅

Les tests permettent actuellement d'utiliser la méthode intégrée Object.keys() , mais je pense que les campeurs obtiennent une meilleure pratique en utilisant for...in combiné avec Object.hasOwnProperty() .

Programmation orientée objet: itérer sur toutes les propriétés :

(RÉSOLU EN STAGING) ✅

Je viens de découvrir que ce défi a le même problème - il permet d'utiliser Object.keys() Comme je ne pense toujours pas que cela devrait être autorisé dans ces défis, je vais créer un PR en ajoutant le cas de test à partir de cette ligne

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

Résoudre ce problème tout de suite: sourire:

Programmation orientée objet: changer le prototype en un nouvel objet

Instructions et tests insuffisants. Est-ce que describe et eat existent juste sur le prototype , ou devraient-ils être des fonctions?

Je pense que nous devrions ajouter des tests pour vérifier que ce sont des fonctions.

Programmation orientée objet: n'oubliez pas de définir la propriété du constructeur lors du changement de prototype

PR soumis: white_check_mark:

Ce défi devrait probablement formater la "propriété du constructeur" comme <code>constructor</code> property pour augmenter la lisibilité et la cohérence. Qu'est-ce que tu penses?

Par exemple, le message de test utilise ce format.

Une suggestion générale est de remplacer les instructions let par const pour afficher les meilleures pratiques. Cette vidéo de @mpj l' explique bien!

Programmation orientée objet: réinitialisation d'une propriété de constructeur héritée :

PR soumis: white_check_mark:

Faute de frappe mineure: supertype's devrait probablement être supertype

Programmation orientée objet: utilisez un IIFE pour créer un module :

PR soumis: white_check_mark:

Petite faute de frappe: "Voici un exemple d'utilisation:" devrait être remplacé par "Voici un exemple d'utilisation:"

Je travaille sur un PR pour https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277447340

Une autre suggestion générale: je pense que nous devons changer les exemples pour que les campeurs ne puissent pas simplement copier l'exemple et changer 1-2 choses pour relever le défi.

Les exemples doivent montrer le concept, mais pas utiliser les propriétés ou les méthodes utilisées par le défi lui-même. De cette façon, je pense que les gens apprendront davantage de chaque défi.

Ditch Custom CSS pour Bootstrap

Le samedi 4 février 2017 à 21h11, Samuel Plumppu [email protected]
a écrit:

Une autre suggestion générale: je pense que nous devons changer les exemples pour
les campeurs ne peuvent pas simplement copier l'exemple et changer 1-2 choses pour compléter le
défi.

Les exemples doivent montrer le concept, mais pas utiliser des propriétés ou des méthodes
qui sont utilisés par le défi lui-même. De cette façon, je pense que les gens apprendront
plus de chaque défi.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment-277463832 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AX9USApjW3rwocbHWe2yoFLV0RegbkCCks5rZL9SgaJpZM4LxApU
.

@iansibindi Il semble que vous soyez abonné à tous les messages de ce référentiel. Pour le désactiver, visitez https://github.com/freecodecamp/freecodecamp et cliquez sur «Unwatch» en haut à droite.

Désolé pour le dérangement!

@Greenheart Je trouve qu'il est un peu difficile de suivre chacun d'entre eux même avec les liens - je suppose que j'aurais peut-être dû ouvrir un numéro supplémentaire pour chacun! Je voulais aussi ajouter une liste de contrôle aux commentaires originaux.

Je vais commencer à faire un premier examen des PR, mais pensez-vous que vous pourriez ajouter un commentaire à chacun des commentaires originaux s'ils ont un PR ouvert pour eux afin que nous puissions suivre les problèmes qui ont été résolus?

@ no-stack-dub-sack Haha je dois admettre que je ne peux pas le suivre moi-même non plus, j'ai juste continué à poster! :sourire:

J'ajouterai un grand "PR ouvert" (avec un lien vers celui-ci) au début de chaque commentaire qui est WIP / corrigé.

@Greenheart Parfait! Merci! J'ai passé en revue les premiers PR

Je vais réparer https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277457211

Je vais réparer https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277459744

Je vais réparer https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277447340

@ no-stack-dub-sack D'accord, il reste encore quelques choses à faire ici mais j'ai résolu certaines d'entre elles aujourd'hui!

Oups, refermé: en riant:

@Greenheart Whoa! Un retour en arrière - y a-t-il quelque chose à faire dans celui-ci? Des améliorations majeures ont été apportées!

@ no-stack-dub-sack Je ne sais pas - il reste des choses à faire selon les commentaires ci-dessus, mais elles ont peut-être été résolues ailleurs?

Je pense que ce n'est pas encore réglé. Faites-moi savoir si vous pensez autrement

Excellent travail tout le monde. Je ferme ce numéro et nous pourrons rouvrir des problèmes plus spécifiques à mesure qu'ils surviennent.