Posty

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...

Mam nową bibliotekę :)

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...

TIL: linie w SVG

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

Niedzielny zrzut linków #11

10 Great Sites for UI Design Patterns Coś na temat UX. Anders Hejlsberg on Modern Compiler Construction Anders Hejlsberg* opowiada o tym, w jaki sposób wygląda kompilator nowego typu (używany np. przy pisaniu kodu w C# w Visual Studio) i w jaki sposób różni się od starego podejścia. *jak prawi wikipedia: "The original author of Turbo Pascal and the chief architect of Delphi. He currently works for Microsoft as the lead architect of C#[1] and core developer on TypeScript." Ciasteczka Brownie Bo akurat teraz zrobiłem wg tego przepisu. Jeszcze nie wiem, jak wyjdą (chłodzą się).

Niedzielny zrzut linków #10

Clean Architecture Cheat Sheet Mała ściągawka z różnymi wskazówkami, na temat tego, w jaki sposób mieć "czystą architekturę" w kodzie. Julia Galef (Kanał na Youtube) "Insights from and explanations of philosophy, rationality, science and more. By Julia Galef (http://juliagalef.com) all-the-widgets Film z 1990, na którym pokazują szczegóły widżetów GUI, jakie do tej pory istniały (Zadziwiające, że od tamtego czasu niewiele się zmieniło w GUI - praktycznie to, co znamy teraz, już wtedy istniało).

Niedzielny zrzut linków #9

React Sight Visualization tool for React, with support for Fiber, Router (v4), and Redux The Dating Scientist "India's first original web series on Data Science." Serial komediowy o data scientistach

Jak nazywać?

Jestem zwolennikiem krótkich nazw. Niech nazwa funkcji czy klasy będzie jednym słowem. Czasem dwoma. Klasy o nazwach typu  ObjectFactoryCreatingFactoryBean łamią moje poczucie stylu. Parametry też funkcja powinna mieć w niewielkiej liczbie. Jeśli można, winno być to zero. Jeśli chcemy, możemy dodać również parametr czy dwa. Jednak dalsza ich liczba to przesada*.   Ciężko zapamiętać wtedy kolejność. Lepszym rozwiązaniem byłoby wtedy przekazanie tablicy albo obiektu. Uzasadnionym wyjątkiem być może mogłaby być funkcja, która działałaby jak `console.log` - to znaczy brałaby  wszystkie końcowe argumenty i robiła z nimi dokładnie to samo. * dodane 3.10.2017: no, może trzy parametry jeszcze ujdą - nie chodzi o to, żeby się kurczowo trzymać liczby parametrów, tylko o to, żeby nie robić bałaganu. Czasem nawet 4 parametry będą ok, np. moglibysmy mieć createRectangle(x, y, width, height) i byłoby to dalej intuicyjne. Jednak nawet wtedy rozważyłbym api createRectangle({x: 0, ...