JavaScript funkcyjnie. Zrównoważone, pragmatyczne programowanie funkcyjne w JavaScript - ebook

Słowo wstępne

Nie jest tajemnicą, że należę do maniaków programowania funkcyjnego. Propaguję idee i funkcyjne języki programowania, gdzie tylko mogę, próbuje czytać najnowsze prace naukowe i studiuję abstrakcyjną algebrę w wolnym czasie. Nawet w JavaScripcie odmawiam pisania nieczystych programów, co doprowadziło do powstania książki Professor Frisby’s Mostly Adequate Guide to Functional Programming. Tak, jestem całkowitym dogmatycznym zelotą.

Nie zawsze tak było… Kiedyś fascynowałem się obiektami. Kochałem modelowanie „prawdziwego świata”. Byłem wynalazcą syntetycznych automatów, dłubałem przy nich nocą, aby osiągnąć mistrzowską precyzję. Byłem twórcą samoświadomych kukiełek, przebierającym palcami po klawiaturze, aby tchnąć w nie życie – prawdziwy Geppetto 1337 h4x0r. Jednak po pięciu solidnych latach pisania kodu obiektowego okazało się, że nigdy nie byłem zadowolony z wyniku. Nigdy nie był on dla mnie dość dobry. Straciłem wiarę, że prosty, elastyczny kod w rozsądnej skali jest w ogóle osiągalny.

Doszedłem do wniosku, że spróbuję czegoś innego: programowania funkcyjnego (FP). Zacząłem parać się funkcyjnymi pomysłami w moim dotychczasowym kodzie i ku przerażeniu współpracowników nie miałem pojęcia, co właściwie robię. Kod, jaki pisałem wtedy, był okropny. Potworny. Cyfrowy ściek. Powodem był brak jasnej wizji lub celu w tym, co chciałem osiągnąć. Nie miałem mojego Jiminy’ego Świerszcza, który by mnie poprowadził. Minął długi czas i dużo śmieciowych programów, zanim doszedłem do tego, czym jest FP.

Po tej całej zabałaganionej eksploracji czuję, że programowanie funkcyjne dało mi to, co obiecywało. Istnieją czytelne programy! Istnieje możliwość ponownego ich wykorzystania! Nie muszę wymyślać swego modelu, mogę go odkrywać. Stałem się sprytnym detektywem odkrywającym rozpowszechnione spiski, mając tablicę korkową pełną dowodów matematycznych. Jak Cousteau wieku cyfrowego, odkrywałem cechy tej dziwnej krainy w imię nauki. Nie jestem doskonały i wiele się jeszcze muszę nauczyć, ale nigdy praca nie przynosiła mi tyle satysfakcji i nigdy tak nie cieszyły mnie jej rezultaty.

Gdyby taka książka istniała, gdy zaczynałem, moje przejście do świata programowania funkcyjnego byłoby znacznie łatwiejsze i mniej destrukcyjne. Ta praca przynosi dwojakie korzyści¹: nie tylko nauczy, jak skutecznie używać w naszym codziennym kodzie FP różnych konstrukcji, lecz także, co ważniejsze, da nam cel – podstawowe zasady, które pozwolą nam utrzymać kierunek.

Nauczycie się lekkiej funkcyjności: paradygmat, który Kyle wyraził jako pierwszy, aby umożliwić programowanie funkcjonalne, dając równowagę i interoperacyjność z resztą świata JavaScriptu. Zrozumiecie podstawy, na których zbudowane jest czyste programowanie funkcyjne, bez konieczności wpisywania się w jego paradygmat w całości. Zyskacie umiejętności praktykowania i analizowania FP bez konieczności przepisywania istniejącego kodu, aby lepiej współpracował z nowym. Możecie zrobić krok do przodu w swoje karierze w dziedzinie oprogramowania, bez cofania się i bezcelowego błądzenia, jak się to mi zdarzyło przed laty. Współpracownicy i koledzy ucieszą się!

Kyle to świetny nauczyciel znany ze swojego niezmordowanego dążenia do pokazania całości, bez pozostawiania niezbadanych zakątków i luk, który jednocześnie ma empatię dla ciężkiego losu uczących się. Jego styl współgra z branżą, podnosząc nas wszystkich na wyższy poziom. Jego praca ma trwałe miejsce w historii języka JavaScript i wielu ma odnośniki do nich w zakładkach. Jesteście w dobrych rękach.

Programowanie funkcyjne ma wiele różnych definicji. Definicja programisty Lispa jest całkiem odmienna od perspektywy Haskella. FP w OCaml w niewielkim stopniu przypomina paradygmaty znane z Erlanga. Znaleźć można nawet kilka konkurujących definicji w JavaScripcie. Jest jednak coś, co to wszystko wiąże ze sobą – dość mglista definicja, którą można zrozumieć, gdy się ją widzi, trochę jak obsceniczność (niektórzy nawet twierdzą, że FP jest obsceniczne!), a w książce tej bez wątpienia udaje się uchwycić ten aspekt. Wynik końcowy nie będzie w niektórych przypadkach uznany za specyficzny, ale wiedza tu nabyta bezpośrednio odnosi się do dowolnego rodzaju FP. Ta książka jest wspaniałym miejscem do rozpoczęcia podróży przez FP. Zaczynaj, Kyle…

Brian Lonsdorf (@drboolean)Wprowadzenie

Monada jest tylko monoidem w kategorii endofunktorów.

Czy nie straciłem właśnie czytelników? Nie martwcie się, ja też byłbym zagubiony! Wszystkie te terminy, które znaczą coś tylko dla osób wprowadzonych w programowanie funkcyjne (FP), mogą brzmieć jak bełkot dla pozostałych osób.

Z tej książki nie dowiecie się, co te słowa znaczą. Jeśli ktoś tego szuka, niech szuka dalej. W istocie jest wiele książek, które od razu uczą nas FP, od początku do końca. Te słowa mają istotne znaczenie i przy formalnej szczegółowej nauce FP, każdy z pewnością je pozna.

Ale ta książka całkiem inaczej podchodzi do tematu. Zaprezentuję tu najbardziej podstawowe pojęcia FP od początku do końca, z mniejszą liczbą specjalnych lub nieintuicyjnych terminów, które pojawiają się w innych książkach o FP. Próbuję przyjąć praktyczne podejście do każdej zasady, zamiast spojrzenia czysto akademickiego. Bez wątpienia będzie tu terminologia. Ale jej wprowadzanie będzie ostrożne i celowe, z wytłumaczeniem, po co one są, i dlaczego są ważne.

Niestety nie jestem posiadaczem karty członkowskiej FP Cool Kids Club. Nigdy nikt formalnie nie uczył mnie, jak programować w FP. I choć mam za sobą studia wyższe i niezłą wiedzę matematyczną, zapis matematyczny nie jest w zgodzie z rozumieniem programowania przez mój mózg. Nigdy nie napisałem ani jednego wiersza programu w języku Scheme, Clojure czy w Haskelu. I nie jestem ze starej szkoły programistów Lispa.

Brałem udział w dyskusjach na wielu konferencjach na temat FP, przy każdej mając desperacką nadzieję, że tym razem wreszcie zrozumiem, o co chodzi w tym całym mistycyzmie związanym z programowaniem funkcyjnym. I za każdym razem odchodziłem sfrustrowany, wszystkie te nowe terminy mieszały mi się w głowie, a ja nie miałem pojęcia, czy i czego się nauczyłem. A najdłużej nie mogłem dojść, o co w tym wszystkim chodzi.

Mając te wszystkie doświadczenia, powoli zbierałem kawałki ważnych pojęć, które wydawały się zbyt naturalne dla formalisty w zakresie FP.

Uczyłem się powoli, pragmatycznie i doświadczalnie, a nie w sposób akademicki z właściwą terminologia. Pewnie każdemu z was zdarzyło się znać jakiś temat przez długi czas, a potem dowiedzieć się, że ma on jakąś nazwę, której wcale nie znaliście!

Może jesteście podobni do mnie. Słyszałem od lat określenia takie jak „map-reduce” czy „big data” w różnych branżach, nie wiedząc, czy są one naprawdę. W rezultacie nauczyłem się co robi funkcja map(..) – na długo przed tym, zanim dowiedziałem się, że działania na listach są jednym z fundamentów na ścieżce programisty funkcyjnego i dlaczego są takie ważne. Wiedziałem czym jest odwzorowanie (map) na długo przed tym, zanim dowiedziałem się, że nazywa się map(..).

W końcu zacząłem zbierać okruchy zrozumienia w zbiór, który nazywam FLP (Functional-Light Programming, „programowanie lekko funkcyjne”).

Misja

Ale dlaczego tak ważna jest nauka programowania funkcyjnego, nawet w lekkiej postaci?

Zacząłem w coś wierzyć w ostatnich latach tak głęboko, że jest to niemal wiara religijna. Wierzę, że programowanie dotyczy ludzi, a nie kodu. Wierzę, że kod jest pierwszym i podstawowym środkiem komunikacji między ludźmi, a to, że instruuje także komputer, jest tylko efektem ubocznym (można tu usłyszeć mój stłumiony chichot).

Widzę to tak, że programowanie funkcyjne dotyczy w istocie stosowania w kodzie dobrze znanych, zrozumiałych i sprawdzonych wzorców, aby unikać błędów, które sprawiają, że kod jest trudniejszy do zrozumienia. Z tego punktu widzenia FP – lub też FLP! – może być jednym z najważniejszych zestawów narzędzi, jakie może pozyskać deweloper.

Przekleństwem monady jest, że – gdy się ją zrozumie – traci się zdolność do wytłumaczenia jej komukolwiek innemu.

------------------------------------------------------------------------

Douglas Crockford 2012 „Monads and Gonads” https://www.youtube.com/watch?v=dkZFtimgAcM)

Mam nadzieję, że ta książka „być może” (ang. Maybe – gra słów z wzorcem FP) przełamie ducha tego przekleństwa, choć nie będę tu wspominał o „monadach”, aż do samych dodatków końcowych.

Formalne podejście programisty FP często zakłada, że prawdziwa wartość FP polega na stosowaniu w zasadzie w 100% podejścia wszystko-albo-nic. Wierzy się, że jeśli używamy FP w części swojego programu, a w innej części nie, to cały program jest zanieczyszczony przez rzeczy spoza FP, więc traci tyle, że nie warto stosować FP.

Mówię wyraźnie: jest to absolutnie fałszywe. Głupotą jest dla mnie sugerowanie, że ta książka może być dobra tylko wtedy, jeśli w całej użyję idealnej gramatyki i strony czynnej. Jeśli popełnię jakieś błędy, to zniszczę jakość całej książki. To nonsens.

Im więcej piszę jasnym, spójnym przekazem, tym lepsze będą efekty dla czytelników. Ale nie jestem idealnym autorem. Niektóre fragmenty są napisane lepiej od innych. Ale części, które mógłbym poprawić, nie deprecjonują innych części książki, które są użyteczne.

I podobnie jest z kodem. Im więcej zastosujemy tych zasad w większej części naszego kodu, tym lepszy będzie kod. Używajmy ich przez 25% czasu i otrzymamy pewne korzyści. Używajmy przez 80% czasu, a zobaczymy więcej korzyści. Zapewne z pewnymi wyjątkami, gdyż nie ma w tym tekście stwierdzeń bezwzględnych. Zamiast tego jest mowa o aspiracjach, celach i zasadach, do których trzeba dążyć. Będzie mowa o pragmatyzmie i kompromisach.

Zapraszam w podróż do najbardziej użytecznych i praktycznych podstaw FP. Wszyscy możemy się wiele nauczyć!Rozdział 2. Natura funkcji

Programowanie funkcyjne to nie jest po prostu programowanie ze słowem kluczowym function. Gdyby to było tak proste – mógłbym w tym miejscu zakończyć książkę! Niemniej funkcje w istocie są centralnym elementem FP. A sposób ich używania sprawia, że nasz kod staje się funkcyjny.

Ale czy w ogóle wiecie, co naprawdę znaczy funkcja?

W tym rozdziale położymy fundament pod resztę książki, analizując podstawowe aspekty funkcji. W zasadzie jest to przegląd wszystkiego, co nawet nieprogramista powinien wiedzieć o funkcjach. Ale z pewnością, jeśli chcemy wyciągnąć najwięcej z pojęcia FP, musimy znać funkcje od góry do dołu.

Zbierzmy się w sobie, gdyż w funkcjach jest znacznie więcej, niż nam się wydawało.

Czym jest funkcja?

Pytanie „Czym jest funkcja?” powierzchownie ma dość oczywistą odpowiedź: funkcja to kawałek kodu, który można wykonać jeden lub więcej razy.

Choć definicja ta jest rozsądna, brakuje jej ważnej treści, która jest istotą funkcji w jej zastosowaniu w FP. Zagłębmy się więc w temat, aby w pełni zrozumieć funkcje.

Krótki przegląd matematyczny

Wiem, że obiecałem w miarę możliwości unikać matematyki, ale znieście to przez chwilę, aby zanim przejdziemy dalej, szybko przyjrzeć się kilku podstawowym sprawom związanych z funkcjami i wykresami w algebrze.

Czy pamiętacie ze szkoły naukę o f(x)? A co z równaniem y = f(x)?

Przypuśćmy, że równanie jest zdefiniowane tak: f (x) = 2x² + 3. Co to oznacza? Co znaczy narysowanie wykresu tego równania? Oto jego wykres:

f (x) = 2x² + 3

Możemy zauważyć, że jeśli dowolną wartość x, powiedzmy 2, wstawimy do równania, to otrzymamy wynik (11). Czym jednak jest 11? Jest to wartość zwrotna funkcji f(x), która zgodnie z wcześniejszym ustaleniem reprezentuje wartość y.

Innymi słowy, możemy wybrać interpretację wartości wejściowych i wyjściowych jako punktu (2,11) na krzywej z wykresu. Dla każdej wartości x, którą wstawimy, możemy otrzymać inną wartość y, która stanowi z nią parę jako współrzędna punktu. Mamy punkty (0,3) lub (-1,5). Gdy złożymy te wszystkie punkty razem, otrzymamy wykres krzywej parabolicznej, pokazanej na rysunku.

A co to wszystko ma wspólnego z FP?

W matematyce funkcja zawsze pobiera dane z wejścia i zawsze daje wyniki na wyjściu. Terminem, który często słyszymy w kręgach FP, jest „morfizm”. Jest to wyszukany sposób na opisanie zbioru wartości, które są odwzorowywane na inny zbiór wartości, jak wejścia funkcji są powiązane z jej wyjściami.

W algebrze te wejścia i wyjścia są często intepretowane jako zestawy współrzędnych do wykreślenia. Jednak w naszych programach możemy zdefiniować funkcje z różnymi rodzajami wejść i wyjść, mimo że będą one rzadko intepretowane wizualnie na wykresie funkcji.

Funkcje a procedury

Dlaczego więc mówimy o matematyce i wykresach? Ponieważ w istocie programowanie funkcyjne dotyczy używania funkcji jak funkcji w tym matematycznym sensie.

Jesteście przyzwyczajeni do myślenia o funkcjach jak o procedurach. Na czym polega różnica? Procedura to arbitralny zbiór funkcjonalności. Może mieć wejścia lub nie. Może mieć wyjście (wartość zwracana przez słowo kluczowe: return) lub nie.

Funkcja pobiera wejścia i zdecydowanie zawsze ma wartość zwrotną return.

Jeśli planujecie wykorzystywać programowanie funkcyjne, powinniście używać jak najwięcej funkcji, unikając, gdzie tylko można procedur. Wszystkie nasze funkcje (function) powinny pobierać wejście i zwracać wyjście (return).

Dlaczego? Odpowiedź na to pytanie ma wiele poziomów znaczenia, które będziemy odkrywać w tej książce.

Wejście funkcji

Do tej pory możemy wyciągnąć wniosek, że funkcje potrzebują wejścia. Ale popatrzmy, jak działa wejście funkcji.

Czasami słyszymy, jak ktoś określa wejście funkcji jako „argumenty”, a czasami jako „parametry”. O co w tym wszystkim chodzi??

Argumenty to wartości przekazywane do funkcji, a parametry to nazwane zmienne wewnątrz funkcji, które otrzymują te przekazane wartości. Na przykład:

function foo(x,y) {

// ..

}

var a = 3;

foo( a, a * 2 );

a i a * 2 (a właściwie wynik działania a * 2, którym jest tu 6) są argumentami wywołania foo(..). Natomiast x i y to parametry, które otrzymują wartości (odpowiednio 3 i 6).

Uwaga

W JavaScripcie nie ma wymagania, aby liczba argumentów była zgodna z liczbą parametrów. Jeśli podamy więcej argumentów, niż zadeklarowaliśmy parametrów, to wartości są przekazywane bez przeszkód. Dostęp do tych wartości może nastąpić na kilka innych sposobów, w tym przez stare dobre obiekty określane jako argumenty (arguments), o których słyszeliśmy wcześniej. Jeśli przekażemy mniej argumentów, niż zadeklarowano parametrów, to każdy dodatkowy parametr jest traktowany jako zmienna „niezdefiniowana”, co oznacza, że jest ona obecna i dostępna w zakresie działania funkcji, ale zaczyna działanie jako pusta, niedefiniowana wartość (undefined).

Wartości domyślne parametrów

Od wersji ES6 parametry mogą przyjmować wartości domyślne. W takim przypadku, gdy argument dla danego parametru nie zostanie przekazany lub zostanie przekazany z wartością undefined, zostanie zastąpiony domyślnym wyrażeniem.

Rozważmy:

function foo(x = 3) {

console.log( x );

}

foo(); // 3

foo( undefined ); // 3

foo( null ); // null

foo( 0 ); // 0

Dobrą praktyką jest zastanowienie się na przypadkami domyślnymi, co może pomóc przy korzystaniu z funkcji. Jednak ustalanie wartości domyślnych dla parametrów prowadzi do większej złożoności w sensie czytelności i zrozumienia różnych przypadków wywoływania funkcji. Należy rozsądnie korzystać tej możliwości.

Zliczanie wejść

Liczba argumentów funkcji oznacza „oczekiwanie”, ile argumentów powinniśmy do niej przekazać. Jest ona określona przez liczbę parametrów, które zostały zadeklarowane:

function foo(x,y,z) {

// ..

}

foo(..) oczekuje trzech argumentów, gdyż ma trzy zadeklarowane parametry. Ten licznik nosi określoną nazwę: argumentowość. Jest to liczba parametrów w deklaracji funkcji. Argumentowość foo(..) wynosi 3.

Ponadto funkcja o argumentowości 1 nazywana jest „jednoargumentową”, funkcja o argumentowości 2 jest „dwuargumentowa”, a funkcja o argumentowości 3 lub więcej – „wieloargumentowa”.

Możemy chcieć sprawdzić odwołanie do funkcji podczas wykonania, aby określić jej argumentowość. Można to zrobić za pomocą własności length w odwołaniu do tej funkcji:

function foo(x,y,z) {

// ..

}

foo.length; // 3

Jednym z powodów określania argumentowości podczas wykonywania jest sprawdzenie, czy kawałek kodu otrzymał odwołanie do funkcji z wielu źródeł i wysłał różne wartości zależnie od argumentowości każdej z nich.

Na przykład wyobraźmy sobie przypadek, gdzie odwołanie do funkcji fn może oczekiwać jednego, dwóch lub trzech argumentów, ale na ostatniej pozycji zawsze chcemy przekazać zmienną x:

// `fn` jest ustawione na odwołanie do jakiejś funkcji

// `x` Ma jakąś wartość

if (fn.length == 1) {

fn( x );

}

else if (fn.length == 2) {

fn( undefined, x );

}

else if (fn.length == 3) {

fn( undefined, undefined, x );

}

Wskazówka

Własność length funkcji jest tylko do odczytu i zostaje określona w momencie definicji funkcji. Należy ją traktować jako istotny element metadanych, opisujący coś związanego z przewidywanym wykorzystaniem funkcji.

Trzeba mieć świadomość, że są konkretne odmiany list parametrów, które sprawiają, że własność length funkcji informuje o czymś innym, niż można by oczekiwać:

function foo(x,y = 2) {

// ..

}

function bar(x,...args) {

// ..

}

function baz( {a,b} ) {

// ..

}

foo.length; // 1

bar.length; // 1

baz.length; // 1

A co ze zliczaniem liczby argumentów otrzymanych w aktualnym wywołaniu funkcji? Tu mamy sytuację, która kiedyś była trywialna, ale teraz będzie nieco bardziej skomplikowana. Każda funkcja ma dostępny obiekt arguments (podobny do tablicy), który przechowuje odwołania do każdego przekazanego argumentu. Możemy więc sprawdzić własność length dla arguments, aby określić, ile zostało w rzeczywistości przekazanych:

function foo(x,y,z) {

console.log( arguments.length );

}

foo( 3, 4 ); // 2

Od wersji ES5 (a konkretnie trybu ścisłego), arguments jest przez niektórych uważane za przestarzałe. Wielu unika stosowania go, o ile jest to możliwe. W JS „nigdy” nie usuwamy kompatybilności wstecznej, niezależnie od tego, w jakim stopniu to może pomóc w przyszłym rozwoju, więc arguments nigdy nie zostanie usunięte. Ale obecnie często zaleca się, aby unikać go, gdy tylko jest to możliwe.

Sugeruję jednak, że arguments.length, i tylko ono, może być stosowane w przypadkach, gdy musimy uważać na liczbę przekazywanych argumentów. W przyszłej wersji JS może ewentualnie zostanie dodana własność, która zaoferuje możliwość określenia liczby przekazanych argumentów, bez konsultacji z arguments.length. Jeśli tak się stanie, to będziemy mogli całkiem porzucić arguments!

Ostrożnie: nigdy nie należy uzyskiwać dostępu do argumentów według pozycji, jak arguments. Trzymajmy się jedynie arguments.length i tylko wtedy, gdy musimy to robić.

Poza tym jak uzyskamy dostęp do argumentu, który został przekazany na pozycji poza liczbą zadeklarowanych parametrów? Odpowiem na to za chwilę: ale najpierw musimy cofnąć się o krok i zapytać się: „Dlaczego mogę chcieć to zrobić?”. Poważnie. Pomyślcie o tym uważnie przez minutę.

To zdarza się dość rzadko. Nie powinno to być coś, czego zwykle oczekujemy lub na czym się opieramy przy pisaniu naszych funkcji. Jeśli okaże się, że mamy taki scenariusz, spędźmy dodatkowych 20 minut, próbując zaprojektować interakcje z funkcją w inny sposób. Nazwijmy ten dodatkowy argument, nawet jeśli jest to sytuacja wyjątkowa.

Sygnaturę funkcji, która akceptuje nieokreśloną liczbę argumentów, określa się jako funkcję ze zmienną liczbą argumentów. Niektórzy wolą ten rodzaj funkcji, ale moim zdaniem większość programistów FP unika tego, jeśli to możliwe.

OK, na razie wystarczy.

Powiedzmy, że chcemy mieć dostęp do argumentów w sposób pozycyjny, podobny do tablicy, zapewne dlatego, że chcemy mieć dostęp do argumentu, który nie ma dla swojej pozycji formalnego parametru. Jak możemy to zrobić?

Na pomoc przychodzi ES6! Zadeklarujmy naszą funkcję za pomocą operatora ... – określanego różnie, jako „rozprowadzający” (spread), „spoczynkowy” (rest) lub (co ja preferuję) „zbierający” (gather):

function foo(x,y,z,...args) {

// ..

}

Czy widzicie na liście parametrów...args? To deklaratywna postać w ES6, która mówi silnikowi, aby odebrał (hmm, „zebrał”) wszystkie pozostałe argumenty (jeśli są), które nie są przypisane do nazwanych parametrów, a następnie umieścił je w jawnej tablicy o nazwie args. args będzie zawsze tablicą, nawet jeśli jest ona pusta. Ale nie będzie zawierać wartości przypisanych do parametrów x, y i z, tylko to, co zostanie przekazane poza tymi trzema pierwszymi wartościami:

function foo(x,y,z,...args) {

console.log( x, y, z, args );

}

foo(); // niezdefiniowane niezdefiniowane niezdefiniowane

foo( 1, 2, 3 ); // 1 2 3

foo( 1, 2, 3, 4 ); // 1 2 3

foo( 1, 2, 3, 4, 5 ); // 1 2 3

Tak więc, jeśli naprawdę chcemy zaprojektować funkcję, która może przyjmować dowolną liczbę przekazywanych argumentów, używamy na końcu ...args (lub innej wybranej nazwy). Mamy teraz prawdziwą, nieprzestarzałą, przyjemną tablicę, z której mamy dostęp do wartości tych argumentów.

Należy zwrócić uwagę na fakt, że wartość 4 jest na pozycji 0 tablicy args, a nie na pozycji 3. Natomiast wartość length nie będzie zawierać tych trzech wartości 1, 2 i 3. ...args zbiera wszystko inne, nie obejmując x, y i z.

Możemy użyć operatora ... na liście parametrów, nawet gdy nie ma zadeklarowanych innych formalnych parametrów:

function foo(...args) {

// ..

}

Teraz args będzie pełną tablicą argumentów, niezależnie od tego, czym one są, a my możemy użyć args.length do określenia, ile dokładnie argumentów zostało przekazanych. I jeśli mamy na to ochotę, możemy bezpiecznie używać args lub args. Ale proszę, nie przekazujcie 318 argumentów.

Tablice argumentów

Co będzie, jeśli zechcemy przekazać także tablicę wartości argumentów do wywołania funkcji?

function foo(...args) {

console.log( args );

}

var arr = ;

foo( ...arr ); // 4

Nasz nowy przyjaciel ... jest w użyciu, ale nie tylko na liście parametrów. Jest też używany na liście argumentów w miejscu wywołania. Ma w tym kontekście odwrotne zachowanie.