TIL składnia destrukturyzacji obiektów w JS jest na opak z dupy
const foo = { fields: ['a', 'b', 'c'] };const { fields: bar } = foo;
Oczekiwałbym, że będzie bar: fields, skoro tak się deklaruje obiekty.
Oczekiwałbym, że będzie bar: fields, skoro tak się deklaruje obiekty.
Dla mnie wszystko w porządku kwestia konwencji.
Ja już jestem nauczony i wolę to, imho dla mnie to zawsze było ok, bo to implikuje lewą i prawą stronę równania.const ob = { a: { b: { c: 21, d: 37 }}};const { a: { b: { c: propWith21, d: propWith37 }}} = ob;
Niż to:const { a: { b: { propWith21: c , propWith37: d }}} = ob;
Bo pierwsze czytam i najpierw zaglądam do wartości której szukam, a potem dopiero opcjonalnie zmieniam jej nazwę.
Z takich kolejności to słusznie ludzie plują na .reduce(), bo to jest głupie, że w:[1, 2, 3].reduce((stack, item) => stack + item, 100);
Czytasz to od pierwszej linii [1, 2, 3].reduce(, potem skok do ostatniej po 100 które jest initial data i dopiero wtedy zaglądasz do ciała funkcji, to technicznie nic nie daje podczas analizy kodu, a raczej właśnie tworzy niepotrzebnie więcej gimnastyki po kodzie. A im więcej linii w callbacku tym bardziej to się uwidacznia.
Normalnie funkcję pętli mają te kluczowe dane na samej górze i reduce wcale nie różni się w tej kwestii.
Ale zrób coś co sie czyta liniowo:let total = 100;[1, 2, 3].forEach(item => { total += item });
To słusznie ci napiszą, że to reduce powinien być:const total = [1, 2, 3].reduce((stack, item) => stack + item, 100);
@kakabix:
Wordle 283 6/6
⬛⬛⬛⬛⬛
⬛⬛🟨🟨⬛
🟨🟨⬛⬛⬛
⬛⬛⬛⬛🟨
⬛🟩🟩🟩🟨
🟩🟩🟩🟩🟩
Pokaż ukrytą treśćW ogóle kakabixy z DREAM i GHOST spoilerują i staram się nie patrzeć przed, bo to w sumie może mi sugerować literki. ;)
@sens'iku wordle dla ciebie, robią wyścigi botów na najlepszy algorytm:
https://freshman.dev/wordle/#/leaderboard