Dlaczego tworzę dodatek do Reduxa?
Dlaczego te moje Feedbacks to jedynie dodatek do Reduxa, a nie cała oddzielna biblioteka?
No cóż. Jest kilka powodów.
1. Ekosystem. możliwość korzystania z całego ekosystemu Reduxa, innych dodatków itp. Nie będę musiał tworzyć całego ekosystemu od nowa. Tworząc bibliotekę od zera musiałbym nawet dev toolsy stworzyć do niej (chociaż może i tak stworzę, albo zmodyfikuję Redux Dev Toolsy, bo mają za mało ficzerów). Tak samo musiałbym tworzyć wiązania do Reacta i sposoby na integrację z wieloma innymi bibliotekami. A w Redux już są tego typu rzeczy.
2. popularność Reduxa. No sorry, ale już powstało ileś alternatyw, a mimo to nikt się nie przebił poza Reduxa, nie wiadomo jak bardzo fajne by było. Taki Mobx ma o wiele więcej ficzerów od Reduxa, a i tak wszyscy tego Reduxa chcą używać (nie jestem fanem Mobx, bo dla mnie tam się zbyt dużo ukrytej magii dzieje. Jednak wolę rozwiązania explicite, a w Mobx masę rzeczy jest implicite. Nie dla mnie. Ale mimo wszystko ficzerami Mobx gniecie Reduxa (ale co z tego? Vue gniecie ficzerami Reacta i też się nie wybija)).
Anyway, najprostsze wyjście, żeby się przebić to chyba po prostu zaakceptować tego Reduxa, tylko spróbować go trochę podrasować (w podobny sposób, w jaki próbuje go podrasować Redux Saga czy inne tego typu biblioteki). To musi być coś jak "turbo-Redux".
3. w społeczności Redux jest wiele zaangażowanych programistów, tych bardziej zaawansowanych, którzy chętnie będą pomagać innym. Tworzenie takiej społeczności od zera wymagałoby mnóstwo czasu i wysiłku.
4. Wreszcie, od strony technologicznej, Redux jest na tyle prostą biblioteką (w sensie rozbudowania), że można łatwo go obudowywać w abstrakcje. Tworzy się po prostu middleware, przechwytuje się akcje, odpala się swoje akcje, podmienia się reducer, żeby robił to, co chcemy. Nie ma dużej filozofii czy ceremonii w tworzeniu samego dodatku do Reduxa. I mało jest zopiniowanych elementów. Middleware robi się tak, że po prostu tworzy się funkcję, która wszystko co trzeba (store, next, akcję) dostaje jako kolejne parametry (parametry w kolejnych domknięciach, tj.
Middleware Reduxa nie musi nawet importować Reduxa, bo wszystko ma wstrzykiwane. Łatwo to potem będzie przerobić na samodzielną bibliotekę, jeśli Redux zacząłby nie wystarczać. Innymi słowy nie będzie tu dużego długu technologicznego czy vendor-lockingu.
No cóż. Jest kilka powodów.
1. Ekosystem. możliwość korzystania z całego ekosystemu Reduxa, innych dodatków itp. Nie będę musiał tworzyć całego ekosystemu od nowa. Tworząc bibliotekę od zera musiałbym nawet dev toolsy stworzyć do niej (chociaż może i tak stworzę, albo zmodyfikuję Redux Dev Toolsy, bo mają za mało ficzerów). Tak samo musiałbym tworzyć wiązania do Reacta i sposoby na integrację z wieloma innymi bibliotekami. A w Redux już są tego typu rzeczy.
2. popularność Reduxa. No sorry, ale już powstało ileś alternatyw, a mimo to nikt się nie przebił poza Reduxa, nie wiadomo jak bardzo fajne by było. Taki Mobx ma o wiele więcej ficzerów od Reduxa, a i tak wszyscy tego Reduxa chcą używać (nie jestem fanem Mobx, bo dla mnie tam się zbyt dużo ukrytej magii dzieje. Jednak wolę rozwiązania explicite, a w Mobx masę rzeczy jest implicite. Nie dla mnie. Ale mimo wszystko ficzerami Mobx gniecie Reduxa (ale co z tego? Vue gniecie ficzerami Reacta i też się nie wybija)).
Anyway, najprostsze wyjście, żeby się przebić to chyba po prostu zaakceptować tego Reduxa, tylko spróbować go trochę podrasować (w podobny sposób, w jaki próbuje go podrasować Redux Saga czy inne tego typu biblioteki). To musi być coś jak "turbo-Redux".
3. w społeczności Redux jest wiele zaangażowanych programistów, tych bardziej zaawansowanych, którzy chętnie będą pomagać innym. Tworzenie takiej społeczności od zera wymagałoby mnóstwo czasu i wysiłku.
4. Wreszcie, od strony technologicznej, Redux jest na tyle prostą biblioteką (w sensie rozbudowania), że można łatwo go obudowywać w abstrakcje. Tworzy się po prostu middleware, przechwytuje się akcje, odpala się swoje akcje, podmienia się reducer, żeby robił to, co chcemy. Nie ma dużej filozofii czy ceremonii w tworzeniu samego dodatku do Reduxa. I mało jest zopiniowanych elementów. Middleware robi się tak, że po prostu tworzy się funkcję, która wszystko co trzeba (store, next, akcję) dostaje jako kolejne parametry (parametry w kolejnych domknięciach, tj.
store => next => action =>
Middleware Reduxa nie musi nawet importować Reduxa, bo wszystko ma wstrzykiwane. Łatwo to potem będzie przerobić na samodzielną bibliotekę, jeśli Redux zacząłby nie wystarczać. Innymi słowy nie będzie tu dużego długu technologicznego czy vendor-lockingu.
Komentarze
Prześlij komentarz