Tslint: la propagation de l'objet ne doit pas être préférée lorsque le premier argument de Object.assign est une instance de classe
Rapport d'erreur
- __TSLint version__ : 5.3
Code TypeScript en train d'être lint
value = Object.assign(new Model(), value)
avec prefer-object-spread activé
Comportement réel
défaillance des peluches, correction automatique pour utiliser la propagation des objets
Comportement prévisible
rien. cette règle doit ignorer les cas où le premier argument de Object.assign est une instance de classe.
- si
--projectest fourni, nous pouvons vérifier si le type du premier argument est de type classe - si aucun projet n'est fourni et que nous ne faisons que des vérifications syntaxiques, le mieux que nous puissions faire est de vérifier
new ...et d'ignorer l'expression
comme indiqué dans https://github.com/palantir/tslint/issues/2618#issuecomment-303879255
adidahiya
Tous les 3 commentaires
Object.assign a des effets secondaires sur son premier argument. (C'est pourquoi TypeScript transpile { ...x, ...y } en Object.assign({}, x, y) .) La règle ne doit s'activer que si le premier argument est un nouveau littéral d'objet.
andy-hanson
le 25 mai 2017
La règle ne doit s'activer que si le premier argument est un nouveau littéral d'objet.
Eh bien, techniquement, vous avez raison. Mais je vois souvent des erreurs où les programmeurs ne font pas attention aux effets secondaires du premier argument et ils fournissent de toute façon une valeur non littérale alors qu'ils voulaient _réellement_ faire la même chose que la propagation d'objets. Donc, je voudrais toujours que cette règle attrape cela. Peut-être qu'il pourrait s'agir d'un opt-in...
adidahiya
le 25 mai 2017
Si le premier argument n'est pas un objet littéral, la règle ne produit une erreur que si le résultat est affecté à quelque chose.
L'attribution de la valeur de retour de Object.assign n'a de sens que si le premier argument est un CallExpression, NewExpression ou similaire. Tout le reste, par exemple un identificateur ou une PropertyAccessExpression, doit toujours être une erreur.
Et cela ne nécessite pas le vérificateur de type.
ajafff
le 25 mai 2017
Questions connexes
dashmug
·
3Commentaires
CSchulz
·
3Commentaires
ypresto
·
3Commentaires
Ne-Ne
·
3Commentaires
mateiacd
·
3Commentaires
Commentaire le plus utile
Si le premier argument n'est pas un objet littéral, la règle ne produit une erreur que si le résultat est affecté à quelque chose.
L'attribution de la valeur de retour de Object.assign n'a de sens que si le premier argument est un CallExpression, NewExpression ou similaire. Tout le reste, par exemple un identificateur ou une PropertyAccessExpression, doit toujours être une erreur.
Et cela ne nécessite pas le vérificateur de type.