J'ai le code suivant:
let pa = 0;
let pw = 0;
let pc = 0;
let pi = 0;
let pr = 0;
this.state.array.data.map((i) => {
if (i.mdn === this.queryParams.mdn && i.sources != null) {
return (i.sources.map((sources) => {
if (sources.source.toString().toLowerCase() === "a") {
pa = sources.t.sessions.u
}
if (sources.source.toString().toLowerCase() === "w") {
pw = sources.t.sessions.u
}
if (sources.source.toString().toLowerCase() === "c") {
pc = sources.t.sessions.u
}
if (sources.source.toString().toLowerCase() === "i") {
pi = sources.t.sessions.u
}
if (sources.source.toString().toLowerCase() === "r") {
pr = sources.t.sessions.u
}
}))
}
},
this.setState({
web: [],
app: [],
preference: [{a: pa}, {w: pw}, {c: pc}, {i: pi}, {r: pr}]
}),
3 Réponses :
Comme Juan Mendes a souligné; S'il n'y a qu'un seul élément à trouver par variable, vous pouvez simplement utiliser une opération de recherche spécifique à cette variable. Pour chaque variable, il ressemblerait à ceci comme ceci;
p>
let pa = 0
const someArray = ['lorem', 'ipsum', 'dolor']
someArray.forEach(function(word) {
pa = word
})
console.log(pa)C'est une bonne suggestion mais ne résout pas le problème, n'est-ce pas?
Cela fait, car (sans autre code présenté dans l'OP), je suppose que Statetate () n'est pas réellement cassé. Puisqu'il fait généralement partie de la réaction ou une autre bibliothèque.
Je ne pense pas que cette réponse a suffisamment de code de OP pour montrer vraiment qu'il répond vraiment à la question posée. La question ne concerne pas l'appel instate , mais plus à voir avec la carte.
Le POST DE L'OP indique clairement: "Une fois que je mets à l'état, il ne le mettait pas réellement défini, il faut juste le 0 et lancer des lancers de là."
Ce n'est pas un excellent exemple, il devrait vraiment être const ba = somearray.find (travail => somécontion (mot))
au lieu d'utiliser Pour préserver l'ordre des clés , Créez un tableau de votre commande souhaitée. P> array.pototype.map code>, essayez array.pototype.foreach code> et définissez un objet de préférence par clé. let order = [ 'a', 'w', 'c', 'i', 'r' ];
preference = {
a : 0,
w : 0,
c : 0,
i : 0,
r : 0
};
this.state.array.data.forEach((item) => {
if (item.mdn === this.queryParams.mdn && item.sources != null) {
return item.sources.forEach((entry) => {
var key = entry.source.toString().toLowerCase();
preference[key] = entry.t.sessions.u;
});
}
});
this.setState({
web: [],
app: [],
preference: order.map(key => ({ [key] : preference[key] }));
}),
Je fais de grandes hypothèses ici depuis que vous n'avez jamais donné l'entrée et je ne fais que sortir de choses que vous avez mentionnées dans les commentaires.
Ce que je pense vraiment que cela devrait être maintenant que je pense que c'est une simple recherche et une carte si le MDN peut être dans plus d'un, que ce serait exiger une autre logique supplémentaire.
Une carte qui modifie l'état est une mauvaise idée. Vous devriez probablement utiliser un
foreach à la place. La carte devrait renvoyer un nouveau tableau sans affecter le reste du code. Le code tel qu'il est très déroutant.En combinaison avec ce que @JuanMendes a suggéré, vous pouvez vraiment rendre cela beaucoup plus propre en remplaçant vos déclarations
si avec un interrupteur. Cela vous permettrait de remplacer tous vos... ToString (). Tolowrase () appelle avec 1.Vous définissez une variable globale ...
PréférencesApp et les autres sont globauxi.sources.map ((sources) - Vous avez le paramètre nommésources et que vous appelez la carte sursources . Vous devriez changer le paramètre sursource ou quelque chose de différent.@Évanbechtol Pas tout le monde accepte avec vous qu'un commutateur est plus propre, toutes les pauses dont vous avez besoin pour y ajouter. Ayant dit cela, ils devraient au moins être
if / ESSES pour le rendre plus clair@ JuanMendes Switch est plus propre imo car le code répète tellement ...
J'ai suggéré un commutateur purement basé sur le fait que cela réduirait le nombre d'appels de fonction, qui ne répondent simplement à la même action. C'est un peu négligé imo.
J'ai remplacé les noms de variable pour réduire le code. J'apprécie l'idée du commutateur, je peux faire cela ... mais encore une fois, je ne cherche pas des plaintes sur le code terriblement écrit, juste une solution.
Carte OS pour prendre un tableau et le changer en autre chose. Vous l'utilisez comme une forloop ....
Il est difficile de dire ce qui ne va pas sans voir un échantillon de
array.data , mais vous voudrez peut-être vérifierRechercheouFiltreY a-t-il une raison pour un tableau avec tous ces objets plutôt qu'un seul objet avec différentes clés:
[{A: PA}, {W: PW}, {C: PC}, {I: PI}, {R : PR}] ? Si c'était un seul objet, ce code pourrait disparaître. Il est étrange d'avoir toutes ces clés différentes sans pouvoir y faire référence sans rechercher dans le tableau,@Markmeyer, je devais finalement regarder et choisir celui avec le plus grand nombre. Je pense qu'un tableau serait plus facile ... et j'ai besoin de savoir quel article a le plus grand nombre
Si vous n'avez pas besoin de toutes les valeurs à l'avant, que non, il serait plus facile lorsque vous le réglez pour ne pas définir celui qui est plus bas ...
@Epascarello Je réalise des personnes comme des commutateurs, mais c'est une préférence. Si l'OP crée une variable pour
sources.source.tostring (). Tolowercase () alors ce n'est pas si mauvaisJ'ai beaucoup d'autres code avec des commutateurs. Le commutateur est vraiment plus facile. Je viens de commencer à travailler sur cette partie, mon problème est de pouvoir définir des variables avec des valeurs ...
Pourquoi ne pas instatiser à l'intérieur de la carte de rappel de carte elle-même plutôt que de l'exécuter comme cet objectif pour l'objet modifié? Je suppose que le rappel est toujours exécutant sur l'objet initial plutôt que sur l'objet modifié.
Y a-t-il plus d'une clé "a"?
N'y a-t-il qu'une correspondance pour
i.mdn === this.queryparams.md ????Non, il n'y a pas plus que 1 a. Et le MDN qui a été lancé dans la requête peut ne pas être dans la liste.