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.
@ToyBlackHat: w jaki sposób logiczniejsze? Tworzysz nowy obiekt i chcesz, żeby miał pole bar z wartością fields. Co w tym logicznego? Pole w obiekcie jest po lewej przy tworzeniu nowego, przy przypisywaniu nowej wartości do istniejącego. To jest kurwa lvalue. A tu jest z pizdy nagle po prawej
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);
Ja już jestem nauczony i wolę to
@Deykun: ano, tak to już bywa. Ostatnio się przestawiłem z długo wyznawanego przeze mnie stylu indentacji Allmana na K&R. Logiki w tej destrukturyzacji nadal dla mnie zupełnie brak, ale ta analogia ze stronami równania całkiem niezła i łatwiej będzie mi to przełknąć xD
Co do kolejności argumentów, to argument o czytaniu linii w callbacku to trochę inwalida, bo kto pcha do callbacków literały dłuższe niż 10 elementów? Zresztą można do tablicy wsadzić initial element z przodu, bo przecież hej, to literał, ty jesteś panem. A jakby był z przodu, to musiałbyś pisać [1,2,3].reduce(0, reducer)
za każdym razem.
Z tego typu dylematów to np. w Pythonie join jest metodą stringa (w której robi on za separator), a nie list czy tupli. I w sumie jest to niby dziwne na pierwszy rzut oka, ale masz w ten sposób załatwione wszystkie iterowalne rzeczy, nie trzeba implementować joina w każdej klasie z osobna.