Dans mon application réactive, j'appelle deux fonctions en fonction du type de propriétaire. Le défi est ici, l'ordre dans lequel j'appelle les paramètres peut différer et basé sur la condition. Actuellement, j'appelle chaque paramètre sur le type de propriétaire.
Comment puis-je le rendre plus dynamique? Y a-t-il un motif pour le rendre plus lisible? Quelqu'un pourrait-il aider? P>
const getCarStats = async(
type,
model,
color,
weight,
source,
make,
year,
id,
owner,
) => {
if (owner === 'A') {
await getAResult(
weight,
source,
make,
year,
id,
owner,
);
}
if (owner === 'B') {
await getBResult(
type,
model,
color,
weight,
make,
year,
id,
owner,
);
}
3 Réponses :
Vous pouvez déplacer des propriétés communes dans le repos. // Autre P> const getCarStats = async (
type,
source,
model,
color,
weight,
make,
year,
id,
owner
) => {
const otherParams = {
color,
weight,
make,
year,
id,
owner,
};
if (owner === "A") {
await getAResult(weight, source, otherParams);
}
if (owner === "B") {
await getBResult(type, model, otherParams);
}
};
Si quelque chose, c'est pire car le code n'est plus auto-documentant. Au moins dans le code donné dans la question, vous pouvez dire quels étaient les paramètres attendus.
Ceci est dynamique, si vous avez besoin de dynamique, vous devez les rendre dynamiques. Pour le document, vous avez déjà des commentaires.
@Patrickroberts Quel est le point de documenter les arguments de la fonction qui ne comptent pas vraiment à ce point spécifique? Ne seraient-ils pas auto-documentés où les autres fonctions sont définies? Il est assez clair que les arguments nommés sont et où se passe le reste.
@ Drewreese alors vous êtes alors obligé de regarder la mise en œuvre de getAreesult () et getbreresult () juste pour comprendre comment vous avez supposé appeler getcarstats () ? Non, ce n'est pas idéal.
Je pense que nous manquons du chapitre de codage propre ici! :-RÉ
@PatrickRoberts idk à propos de vous, mais si je vraiment voulez savoir quelle fonction est-ce que je vais regarder sa définition et implémentation. Ou s'il est déjà documenté, laissez l'intellientense de l'IDE me dire quand je serre simplement sur le nom de la fonction.
@ Drewreese Exactement, vous devriez être capable de survoler tout appel de getcarstats () et être capable de déterminer quels paramètres à y passer, encore moins combien de . Un paramètre ... reste ne doit pas être utilisé pour une liste d'arguments non variadiques et non homogènes.
Voici la question, comment utiliser la fonctionnalité ES6, pas comment documenter. Si vous voulez utiliser l'opérateur de repos ES6. Nous devons y aller avec ça. Autre chose, comme nous avons recommandé, nous ne devrions pas avoir plus de 3 paramètres de l'appelant
@xdepakv ne soyez pas si littéral, ils ne demandent pas spécifiquement à cette approche , juste toute approche meilleure .
Oui! J'ai déjà édité ma réponse. Si tu vois! autre manière suggérée! Un modèle de conception est le choix.
Je ne me soucierais pas à avoir toutes ces variables séparées, mais simplement passer une voiture puis, dans Vous pouvez aussi faire le détruire dans le corps de la fonction. THA contient toutes: getAreesult et getbreresult Vous pouvez déstructurer l'objet en prenant uniquement les accessoires qui vous intéressent:
Dans ce contexte, le attendre ne sert aucun but. retour est suffisant.
Si vous pouviez définir les deux fonctions internes telles que ceci à la place:
const getCarStats = async car => {
if (car.owner === 'A') {
await getAResult(car);
}
if (car.owner === 'B') {
await getBResult(car);
}
};
Ceci est exactement ce que je cherchais! Génial, cela a aidé.
Comment c'est documenté: si (voiture.owner === 'a') {attendre getAreesult (voiture); } Quels sont les paramètres ici, comment saurais-je savoir? Dois-je lire le document pour API A. .. getAreesult (voiture);
@xdepakv C'est un paramètre, avec un nom auto-documentant. ... reste n'est pas un nom auto-documentant et vous laisse avec les questions "combien de paramètres" et "quel ordre". Avec cette approche, il s'agit d'un paramètre et des propriétés de l'objet sont non ordonnées, ce qui n'a pas d'importance quel ordre vous nommez les propriétés. N'est-ce pas gentil?
Je pense que je n'ai pas vu correctement ma réponse! Le préjuge est une mauvaise chose! de toute façon. La fonction ne doit pas avoir à avoir ceci si-d'autre! Vous pouvez rechercher le motif de conception d'usine.
Et ici voiture n'est pas documentée. Si je tape, getcarstats ({id pas d'autocomplete
@xdepakv J'ai regardé votre réponse plusieurs fois. Je n'ai déjà expliqué pourquoi je n'aime pas votre approche initiale et votre deuxième approche aborde les commentaires que j'ai faits, mais c'est juste beaucoup plus verbeux que nécessaire.
Pour ce nombre de paramètres, il serait préférable de transmettre un seul objet avec ces noms comme propriétés plutôt que de les faire des arguments de position
Pourquoi ne passez-vous pas autour d'un objet de voiture? Ensuite, vous n'avez pas à vous soucier de l'ordre des paramètres:
const getcarstats = (voiture) => voiture.owner === "A"? getAreesult (voiture): GetBresult (voiture) .FYI, c'est une interprétation de la valeur, pas la déstructuration de l'objet.
@Patrickroberts qui pourrait être, mais pouvez-vous s'il vous plaît élaborer? Je ne sais pas si je vous ai suivi correctement sur la syntaxe.