@sens: gorący post

@sens: fields: bar logiczniejsze jak dla mnie

@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);

@Deykun: karasie

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.