Redux Vs. RxJS + ngrx / магазин

Пиша тази статия, защото се опитвам да разбера дали трябва да използвам Redux или ngrx / store за следващото си уеб приложение.

Малко история, имам опит с използването на Redux. Работил съм в React среда и интегрирах Redux с Angular1.x изграждане. Проблемирах малко с cyc.js, RxJS, както и с XStream и чух много за реактивно програмиране. В допълнение, аз работя с Angular2 много и Angular2 използва RxJS наблюдаеми като част от основната му рамка. По-специално за логиката като EventEmitter. В допълнение, той го използва като част от своя публичен API, за Forms, както и за HTTP модул. Очевидно е, че ngrx / store най-малкото заслужава кимване на главата.

Искам да преминем задълбочено през реактивното програмиране, по-специално що се отнася до състоянието. На първо място, защото вместо да прескачате директно в реактивното програмиране, за мен има смисъл да се съсредоточа върху управлението на държавата от страна на реактивното програмиране на нещата и след това да се съсредоточа върху реактивното програмиране (признавам си обаче, че вече опитах cyc.js като споменах преди, но регресирам). Като странична бележка, считам, че от късно вече съм в крак с определени библиотеки, просто заради това, че общността се издига зад него, за разлика от това наистина да се опитвам да разбера за себе си дали това е парадигма, която има смисъл. Е, ето ни.

Важно е да се отбележи, че фонът в реактивното програмиране наистина ще постави това в перспектива. Тук можете да намерите страхотен учредителен документ, обсъждащ реактивното програмиране за едновременно програмиране. В него се обсъжда ползата от реактивното програмиране в реално време Progamming a.k.a. Две бележки, които са важни, е че реактивното програмиране е:

1. Асинхронен

2. Детерминиран

По-специално, има много добра статия, описваща защо човек трябва да използва функционално реактивно програмиране като цяло. Въпреки че е от гледна точка на Android Developer, същото може да се прилага за Javascript в много отношения. Трябва да се отбележи, че реактивното програмиране и функционалното реактивно програмиране не са едно и също.

За по-удобен списък, който се фокусира конкретно върху реактивното развитие от страна на клиента (известен още като предния край), намерих следната статия за страхотна.

Ако погледнете по-горе, ако нямате опит в реактивното програмиране, горното трябва да ви ускори с този разговор.

Андре Сталц, когато обсъжда защо трябва да помислите, че Реактивното програмиране наистина докосва сърцевината на всичко това със следното: „Реактивното програмиране повишава нивото на абстракция на вашия код, за да можете да се съсредоточите върху взаимозависимостта на събитията, които определят бизнес логиката…“.

Като се каже, веднага става очевидно защо човек би искал реактивен подход към държавата. По принцип държавата се променя със събития и да можеш да абстрахираш нивото на държавата има пълен смисъл. Дори единственият резултат да е ядрената библиотека да стане по-управляема, бих твърдял, че все още има смисъл. [Да, тя ще бъде обвързана с реактивна библиотека, но ние ще засегнем и това, дори и за React среда]

Интересно е обаче, че това не е причината, поради която ngrx е създаден на първо място. Той всъщност е създаден за „откриване на промяна“ в Angular2, така че асинхронизиращата тръба може да окаже изглед специално за ъглови. Това позволява на човек да деактивира откриването на промени, което ще доведе до повишаване на производителността. Освен това .subscribe (), тъй като работи естествено в реактивни приложения (реактивното е един гигантски модел за наблюдение), нова функция в кодовата база на магазина не се изисква. Подобна функционалност за промяна на състоянието присъства в RxJs.

Ето защо реших следното. Ако се опитвате да интегрирате наблюдаемо / реактивно програмиране във вашето уеб приложение, тогава непременно използвайте ngrx / store. По мое лично мнение би трябвало. Най-определено би трябвало да сте за Angular 2, по подразбиране за Cycle.js (или XStream) и наистина има смисъл да виждаме, че това се случва повече в общността React (според мен XStream).

Ngrx изглежда като жизнеспособният път, който се движи напред, и ние трябва да се опитаме да го възприемем и реактивно програмиране. Особено като се има предвид, че това ще ни доведе по-близо до функционалната парадигма, която толкова съкровяваме. Този, който дори не е успял да има официален каталог на дизайнерски модели (за разлика от обектно ориентирания софтуер).

Това е всичко и не се колебайте да оставяте коментари, които ми казват колко греша или какви биха били страхотни предложения за напред. Последният ангажимент и статия е точно зад ъгъла. Благодаря и продължавайте да бъдете невероятни!