Luke J. Li

Robię pewien projekt, nazwijmy to projektem "S". Nie mówię jeszcze co to, ale wygląda to tak jak na obrazku. Teksty są przykładowe, więc się nie sugerujcie, to nie będzie nic o zwierzętach, tylko to będzie coś dla ludzi (chociaż człowiek to również zwierzę). Nie wygląda to za fajnie, ale wrzucam jako ilustrację tego, że początkowa faza jakiegokolwiek projektu nie musi wyglądać wcale super. To prostu parę randomowych elementów, które gdzieś się tam wrzuca na stronę (i 76 linijek kodu z użyciem React i Mobx). Myślę, że ludzie czasem przesadzają jeśli chodzi o początkowe fazy projektów i próbują już na samym początku robić wszystko super elegancko i "profesjonalnie", mimo, że robią tak naprawdę prototyp, który nawet nie wiadomo czy trafi na produkcję, a jeśli trafi to i tak pewnie za ileś miesięcy. I tracą czas na szlifowanie prototypów. Ja wolę podchodzić w sposób bardziej "lean" i YAGNI. Prototypowanie w brudny sposób jest ok. I to jest w pewien spo

Zmieniłem tło na jasne, żeby wprowadzić trochę przestrzeni na blogu. Ciemny kolor jakoś tak przytłaczał. Coś w tym jest, że ciemność bardziej ogranicza, zawęża fokus, a jasność bardziej uwalnia i rozprasza. Dlatego pewnie filmy najlepiej ogląda się po ciemku, dlatego też pewnie programiści piszą kod zwykle na ciemnym tle. Łatwiej się jest skupić. Z drugiej strony mam wrażenie, że moja kreatywność się rozszerza wtedy, kiedy jasno. Dlatego też w dzień mam najciekawsze pomysły, dlatego też odwracam wzrok z ciemnego okienka edytora. Patrzę w okno. Albo piszę/rysuję coś na kartce papieru, która jest biała. Podobnie jak moje biurko. Jasne i ciemne aspekty programowania. Jasność = kreatywność, projektowanie Ciemność = skupienie, implementacja Nie rozumiem ludzi, którzy myślą nad implementacją patrząc na ekran IDE. Ja tak nie umiem. Dla mnie praca koncepcyjna to coś, co wymaga odejścia od komputera. Albo przynajmniej odwrócenia wzroku. Wtedy mogę rozkminiać. Natomiast jak już rozkmi

Odpowiadam na to pytanie we wpisie na moim drugim blogu:  https://blog.2late.pl/2018/10/zawod-programista-trudny-czy-nie.html

Swoją niesamowitą historię, jaka mi się przytrafiła kilka lat temu, opisałem na moim drugim blogu. Czytajcie:   https://blog.2late.pl/2018/10/miaem-pracowac-na-pododze.html

Więc tak. O ile Redux Saga ma fajny model efektów  to jednak pewne rzeczy poszły w Redux Saga i jej ekosystemie nie do końca dobrze. Najpierw o tym co jest dobre i fajne. Czyli sama zasada działania:   piszesz generator, który zawiera jakąś tam logikę interakcji, a żeby odpalić efekty uboczne to zwracasz sterowanie (przez yield) do interpretera efektów, który wykonuje efekt i zwraca sterowanie z powrotem do generatora. Tym sposobem izolujesz logikę od efektów ubocznych. Bardzo na propsie. Ale jednak... brak integracji ze storem  Czyli coś, co w Feedbacks jest, w Redux Saga nie. W Feedbacks generatory działają w kontekście jakiejś właściwości w store, w Redux Saga działają niejako poza storem, co sprawia, że żeby coś zmienić w storze trzeba wysłać akcję - więc zmieniasz 5 rzeczy, to tworzysz 5 dodatkowych akcji i 5 razy zmieniasz reducery. Masakra. Czyli w zasadzie Redux Saga wcale nie likwiduje reduksowego "boilerplate'u", a tylko dokłada do niego kolejną cegie

Moje Feedbacks coraz bardziej zaczyna przypominać Redux Saga. Nawet generatory już są. To trochę jakby takie coś podobnego do Redux Sagi, tylko bardziej funkcyjne i mocniej zintegrowane ze store'm. Można z reducerów zwracać efekty, one się rozwiązują i wartość idzie z powrotem do store'a. Jeszcze dokumentację zacząłem robić  https://github.com/hex13/feedbacks/blob/master/docs/api.md , ale wciąż jest niepełna. Chociaż jak chcecie zobaczyć jak to wygląda w praktyce to tu jest przykład:  https://github.com/hex13/feedbacks/blob/master/examples/calendar/src/store.js . Anyway, lepiej się tego już dzisiaj zaczynajcie uczyć, to za rok będziecie mogli powiedzieć na rozmowie, że macie już rok doświadczenia w Feedbacks. A myślę, że to może być hit na miarę Sagi albo i samego Reduxa. Taki game changer (dlaczego tak myślę? No po prostu o ile wciąż Feedbacks jest biblioteką młodą i nie wszystko w niej jest, to już widzę, że pozwala to drastyczne zmniejszenie ilości kodu związanego z Redu

W poprzedniej notce zastanawiałem się, czy nie wywalić możliwości zwracania obserwabli z reducerów i zastąpić je obiektami "efektów", jednak po przemyślaniu uznałem, że zostaje to i to. Mimo wszystko zwracanie obserwabli jest to killer-feature i może przypaść do gustu wielu osobom, nawet jeśli będzie miał pewne trade-offy i nawet jeśli sam będę ostrożny w jego używaniu. A i tak kod do tego ficzera jest już napisany i nie mogę go skasować (ponieważ kod rozwiązujący promisy czy obserwable potrzebny mi jest w innych miejscach, w których coś takiego robię), mógłbym jedynie sztucznie zrobić blokadę na zwracanie tego typu rzeczy z reducera, ale byłoby to bezcelowe. Pisałem, że nie będzie to skalowalne, ale tak w zasadzie to zależy od tego, kto będzie to pisał. Myślę, że jest możliwe napisanie czegoś większego na obserwablach tak, żeby to miało ręce i nogi w większej apce. W zasadzie po części w ogóle zacząłem robić tę libkę. Bo wg mnie obserwable są fajnym konceptem, ale brakuje

Zastanawiam się, czy nie wywalić flagowej opcji z mojej biblioteki. A mianowicie fakt, że reducer może zwracać obserwable i opakowane w funkcję promisy. Czyli teraz da się tak zrobić w Feedbacks : function reducer(state, action) { return () => Promise.resolve(123); } albo: function reducer(state, action) { return Rx.interval(1000); } Dlaczego chcę to wywalić? No bo załóżmy, że moja biblioteka będzie używana w dużych projektach. Wtedy takie machinacje obserwablami czy zwracanie asynchronicznych funkcji bezpośrednio z reducerów mogłoby sprawić, że projekt stałby się trudniejszy w debugowaniu albo trudne byłoby robienie jakichś mocnych zmian w implementacji (ponieważ wszystko w środku byłoby sprzężone z tymi obserwablami). Wpadłem na pomysł w jaki sposób mógłbym w bardziej elegancki sposób obsługiwać efekty uboczne. Tzn. dalej reducer zwracałby efekt uboczny, tylko, że nie wprost obserwable/asynchroniczne funkcje, a raczej obiekt z parametrami efektu np. {type: 

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

Piszę właśnie swoją nową bibliotekę. Częściowo jest to kolejna próba naprawienia Reduxa, jednak od poprzednich będzie się różnić tym, że zamiast tworzyć "alternatywę do Reduxa", to postanowiłem jednak napisać do tego Reduxa zwykły dodatek (middleware + automatyczne tworzenie reducera). Biblioteka się nazywa Feedbacks (jak doczytacie dalej, to będzie jasne, skąd ta nazwa). I jest już dostępna na Githubie oraz na npm . A więc Feedbacks zamienia Reduxa w reaktywny silnik stanu , która sam aktualizuje sobie stan na podstawie tego, co zwrócą: - obserwable (celuję głównie w Rx.js, ale rozważam wsparcie dla innych, podobnych bibliotek) - promisy - reducery indywidualne dla każdego "pola" (właściwości) w stanie (trochę jak w combineReducers, ale lepiej, bo dodałem do tego bardziej zaawansowany pattern matching, np. można robić coś takiego: match({type: 'foo', payload: {name: 'bar'}}, (value, action) => 42} i dopasowywać akcję pod kątem tego, co m

1. w SVG istnieją tagi <polygon> oraz <polyline>. Ja zawsze używałem <path> I nie robiłem wcale źle, ponieważ: "In these examples, it would probably be simpler to use the or elements. However, paths are used so often in drawing SVG that developers may be more comfortable using them instead. There is no real performance penalty or bonus for using one or the other." 2. w SVG w path istnieje taki znacznik jak `H` do robienia horyzontalnych linii (to samo można osiągnąć przez L z parametrem x = 0) i parę innych skrótów https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths