Spośród bibliotek kodu funkcyjnego, fp-ts zyskało popularność dzięki skupieniu się na funkcyjnych mapowaniach i monadach, jednak wraz z integracją z Effect zmieniło się w frameworka.
Effect, w przeciwieństwie do poprzednich bibliotek, działa jak framework i wymaga znajomości powiązanych zagadnień, aby korzystać z obiektów Effect.
Effect, podobnie jak Observable w RxJs, używa obiektów otoczonych Effect i przewiduje się, że może stanowić nowy standard w branży Node.js.
W ciągu ostatnich kilku lat programowanie funkcyjne zyskało sporą popularność.
Programowanie obiektowe skupia się na tworzeniu struktur,
natomiast programowanie funkcyjne na zapewnieniu zwięzłości kodu na poziomie szczegółów.
Oczywiście popularność programowania funkcyjnego ma cykliczny charakter i powraca co kilka lat.
Wraz z rosnącą popularnością tego podejścia zaczęły pojawiać się różne biblioteki.
Oczywiście, takie zestawy narzędzi pomagają w programowaniu deklaratywnym.
Jednak to, czego szukamy w programowaniu funkcyjnym, to nie tylko to – chodzi o mapowania, funkcje wyższego rzędu, monady i jeszcze więcej monad.
fp-tsspełniało te wymagania, a jego twórca był prawdziwym entuzjastą programowania funkcyjnego.
Kilka miesięcy temu dowiedziałem się jednak, że ta biblioteka została połączona z Effect.
Dlatego postanowiłem przyjrzeć się bliżej Effect, i okazało się, że jest coś innego.
Podczas gdy fp-tsbyło bardziej biblioteką, Effectwygląda bardziej jak framework.
Aby korzystać z Effect, trzeba mieć podstawową wiedzę na jego temat.
NestJs i NextJsteż wymagają zrozumienia ich mechanizmów.
Biblioteki, jeśli mają dobrze udokumentowany interfejs API, można po prostu pobrać i użyć. Frameworki natomiast wymagają zrozumienia ich specyfiki.
import{Effect,Console}from"effect"let i =1const expensiveTask =Effect.promise(()=>{console.log("expensive task...")returnnewPromise((resolve)=>{setTimeout(()=>{resolve(result ${i++})},100)});})const program =Effect.gen(function*(){console.log("non-cached version:")yield* expensiveTask.pipe(Effect.andThen(Console.log))yield* expensiveTask.pipe(Effect.andThen(Console.log))console.log("cached version:")const cached =yield*Effect.cached(expensiveTask)yield* cached.pipe(Effect.andThen(Console.log))yield* cached.pipe(Effect.andThen(Console.log))})Effect.runFork(program)/*
Output:
non-cached version:
expensive task...
result 1
expensive task...
result 2
cached version:
expensive task...
result 3
result 3
*/
W Effectzamiast obiektów opakowanych w Observable, jak w RxJs, mamy obiekty opakowane w Effect, które są przekazywane dalej,
jakby async było zaraźliwe.
Aby korzystać z obiektów Effect , funkcje, które je wykorzystują, również muszą być typu Effect.
Tak jak w przypadku program w powyższym kodzie.
Oczywiście, istnieje funkcja, która może służyć jako punkt wejścia, ale nie jest ona zbyt elegancka.
Ogólnie rzecz biorąc, forma i czystość Effectjako frameworka sugerują, że może on przynieść nowe rozwiązania i standardy do świata Node.js. Mam nadzieję, że tak się stanie.