Wczoraj - dnia 07 czerwca 2018 - odbył się w Poznaniu 3-ci React Poznan by meet.js. Spotkanie pod szyldem meet.js tyle, że poświęcone całkowicie React’owi. Na spotkaniu można było posłuchać między innymi o react-routerze, asynchronicznym podejściu do reduxa oraz jak kopiować kod ze stack-overflow, żeby się nikt nie skapnął ;) Zapraszam na relację z wydarzenia.

Miejsce i sponsor

Sponsorem wydarzenia był Coders Lab, firma prowadząca szkolenia/warsztaty dla ludzi chcących zostać programistami. Zapytacie co Coders Lab robiło na spotkaniu dla programistów? Otóż szukali ludzi, którzy chcieliby zostać wykładowcami w ich szkole. Nie powiem - bardzo zainteresował mnie ten temat. Tym bardziej, że w Egnyte znam kilka osób, które swoją pierwszą przygodę jako wykładowca w Coders Lab mają już za sobą. Nie zapeszając - zobaczymy jak sytuacja się rozwinie ;) ...

Jeśli chodzi o miejsce to ugościło nas +1 Poznań. Coworking place i chyba mogę tak powiedzieć: “Poznańskie centrum wydarzeń IT”. Miejsce, do którego każdy może przyjść popracować a ponad to każdy miesiąc usiany jest przeróżnymi spotkaniami różnych grup tj. Agile-Poznań, Laravel, MeetJs itd. Uważam, że jest to najlepsze miejsce na tego typu meetupy w jakim byłem :) Duża klimatyzowana sala, dwa projektory, bardzo dobre nagłośnienie, no i lokalizacja w samym centrum Poznania. Jedyny problem to mega duże obłożenie - żeby zorganizować spotkanie w +1 Poznań, trzeba rezerwować termin, dużo dużo wcześniej.

Przygody ze ścieżkowaniem, czyli react-router@4.2.0

Pierwszą prezentację poprowadził Michał Tymuła, który na co dzień pracuje jako wykładowca/mentor w Coders Lab. Tematem jego wystąpienia był react-router w wersji 4.2.0. Na początku bardzo spodobała mi się forma prezentacji, która niestety z czasem stała się bardzo męcząca... Dużo pytań, baaaaaaaaardzo dużo pytań...i to nie były wcale pytania od publiczności do prowadzącego...wręcz przeciwnie. Michał praktycznie przy każdym slajdzie zadawał pytania:

  • Kto pisał w react-router ?
  • Kto pisał w react-router 3?
  • Kto pisał w react-router 4?
  • Czym jest routing?
  • Jak routing ugryźć ?
  • ...

Kilka pytań na rozgrzewkę - jak najbardziej! - ale gdy cała prezentacja oparta jest na pytaniach to robi się to niestety męczące. Jeśli chodzi o wartość merytoryczną - to Michał zaprezentował absolutne podstawy użycia react-routera. Przeszedł od instalacji - przez definicję ścieżek i skończył na wyjaśnieniu jak używać parametrów. Dla osób, które nigdy wcześniej nie miały z tematem do czynienia - wystarczające minimum na start. Bardzo duży plus dla Michała za udostępnienie repozytorium z przykładami + zachęcanie ludzi do forkowania i zabawy z biblioteką. Mi osobiście zabrakło chociażby wspomnienia alternatyw takich jak np. reach/router.

Podsumowując:
(+) płynna forma prezentacji, widać było, że wie o czym mówi,
(+) wprowadzanie do react-router dla początkujących,
(+) udostępnienie repo z przykładami,
(-) pytania, pytania...wszędzie te pytania…

Async actions in redux-like app

Drugim prelegentem był Jacek Tomaszewski. Jacka kojarzę z mojego pierwszego meetjs-summit, na którym prowadził prezentację o grunt/gulp :) Heh...trochę się zmieniło od tego czasu, a frontendową sceną zawładnęły skrypty npm i webpack. Tematem jego prezentacji były akcje asynchroniczne w reduxie i to jak je ugryźć. Widać było, że Jacek z niejednego pieca chleb wcinał i że zna się na tym co mówi. Zaczął od podstaw reduxa, o tym, że reducer z założenia jest pure-function, która zależy tylko od przekazanych argumentów a nie od side-effectów. Słusznie zauważył jednak, że nasz świat nie jest synchroniczny...wręcz za całą pewnością można stwierdzić, że żyjemy w środowisku asynchronicznym. Tak samo jest z naszymi aplikacjami webowymi...zapytania do serwera, timeouty, reagowanie na upływ czasu. Wszystko te operacje to są side-effecty. Na kolejnych slajdach Jacek uraczył nas opisami kilku podejść do asynchroniczności w reduxie. Opowiadał np. o redux-thunk, redux-promise, redux-saga czy redux-effects. Każda biblioteka opatrzona została w przykładowy kod. I właśnie ten przykładowy kod to jedyne do czego mógłbym się przyczepić - formatowanie. Straaaaaaaaaaaaaaaasznie to było nieczytelne. Ekran podzielony na pół...lewe 50% zajmował duży napis z nazwą biblioteki, a prawe 50% kod. Myślę, że gdyby umieścić to w pionie - wyglądałoby to o wiele lepiej ;) ale...czepiam się...jak Tomek Łakomy w swojej ostatniej prezentacji o formatowaniu kodu - ale o tym za chwilę #noSpoilers!.

Podsumowując - Jacek odwalił kawał dobrej roboty. Dużo wiedzy przekazanej w przystępny sposób. Plus za płynną formę prezentacji. Jedyny minus to te przykłady w kodzie, które dla mnie były niestety nieczytelne.

Where is Kitze !?

No właśnie...gdzie? Trzecim prelegentem miał być zagramaniczny gość Kitze. To właśnie na jego prezentację “Navigating the hype-driven frontend development world without going insane” najbardziej ostrzyłem sobie zęby. Niestety Kitze nie mógł do nas wczoraj dojechać. Organizatorzy postanowili jednak nie kończyć na dwóch prezentacjach i dorzucili dodatkowe dwa lighting-talki.

redux-reactors - async cdn.

Po krótkiej przerwie na siku, na scenie pojawił się Zibi. Czy ktoś tu nie zna Zbyszka? No właśnie! Powiedzieć o nim jako o organizatorze meetjs to nie powiedzieć nic ;) ...dlatego przejdźmy do tematu jego lighting-talk’a.

Zibi pociągnął...dalej temat asynchroniczności w reduxie. Grzecznie podziękował Jackowi za przedstawienie rozwiązań opartych na middleware - nie musiał tym samym opowiadać o tym drugi raz. Przedstawił natomiast zupełnie inne podejście...Skoro nasz reduxowy store wystawia API do subskrypcji zmian zachodzących w stanie naszej aplikacji - to dlaczego by nie zapisać się na takie zmiany jakimś dodatkowym handlerem, w którym będziemy mogli dispatchować asynchroniczne akcje? Brzmi zagmatwanie? Nieeee...prościzna ;) Moim zdaniem bardzo ciekawy pomysł, który został nazwany redux-reactors. Podobno cały koncept przedstawiony został w książce https://reduxbook.com/, której autorem jest Henrik Joreteg. Myślę, że nie omieszkam jej sprawdzić w najbliższym czasie ^^. Zbyszek przedstawił też swoją implementację redux-reactora, którą planuje w niedalekiej przyszłości opublikować na npm’ie. Czekam z niecierpliwością.

Prettier

Prettier - czyli jak skopiować kod ze stackoverflow, żeby się nikt nie skapnął ;)

Na koniec scenę przejął nasz poznański mistrz sucharów - Tomasz Łakomy. Jak tylko wszedł na scenę dostałem sms’a od żony, że pranie, które zrobiła przed chwilą wyschło w jakiś magiczny sposób ;) Natomiast ja wiedziałem, że to nie magia...to Tomek zaczął swoją prezentację.

Tematem prezentacji Tomka był Prettier. Narzędzie do formatowania kodu. Bardzo, jak to się mówi, opinionated. Google translate podpowiada, że opinionated to “uparty”, “zawizięty”. I rzeczyiście tak jest. Prettier formatuje nasz kod nie w sposób, w jaki my chcemy, ale w jaki wymyślili to sobie twórcy biblioteki. I z jednej strony to bardzo fajnie - generalnie gdyby wszyscy używali tego narzędzia to cały JS’owy kod na githubie sformatowany byłby w ten sam sposób. Ale z formatowaniem kodu jest taki problem, że ile ludzi tyle opinii. Jedni wolą spacje inni taby, jedni dodają średniki a drudzy nie...w końcu pojedynczy cudzysłów czy podwójny? Wszystko zależy od zespołu w jakim pracujesz. Moim zdaniem w każdym projekcie może być inaczej. Kod ma być przede wszystkim czytelny dla ludzi, którzy go utrzymują. Mi w Prettier przeszkadza tylko jedna rzecz - nie pozwala on na spacje pomiędzy { } w składni JSX. Uważam, że taka spacja daje trochę "oddechu" podczas czytania kodu. Jakoś tak wzrok się mniej męczy...Zobaczie sami:

// Bez prettier
<MyAwesomeComponent prop={ someValue } secondProp={ secondValue } />

//Prettier
<MyAwesomeComponent prop={someValue} secondProp={secondValue} />

I co? Które czytelniejsze? Pierwsze? Drugie? #whoCares? ;) No właśnie, ilu ludzi tyle opinii...

Tomek w trakcie swojej prezentacji rzucił hasłem w stylu:

Użytkowników nie obchodzi jak mamy sformatowany kod…

No pewnie! A czy obchodzi ich czy piszemy w JS’ie czy brainfucku? No nie! Kod jest dla programistów, dla ludzi, którzy ten kod potem utrzymują i rozwijają. Tutaj Tomek z tego co zrozumiałem nie był do końca przekonany. Rzucił coś w stylu:

Czy programiści powinni się martwić formatowaniem? ...czy aby na pewno?

Dodał też, że formatowanie kodu nie zalicza się do wytwarzania oprogramowania. Pytam się dlaczego? :) Jak piszesz książkę to też masz "w pompie" akapity, przecinki, kropki itp.? No nie! Z pisaniem kodu jest trochę jak z pisaniem książki. Wydaje mi się, że Tomek o tym doskonale wie...ale obecnie jest tak zajarany Prettierem, że o tym zapomniał ;). Ton jego prezentacji odebrałem bardzo agresywnie. Tym bardziej po krótkim demie jakie zaprezentował.

Za jednym razem wklepał taką oto linijkę kodu:

<Slide><Heading>Text</Heading></Slide>

Potem zaczął ją ręcznie tweekować...tu dodał enter...tam gdzieś zjechał z tabulacją...i narzekał - że to nie jest programowanie! :) …. No ale gdyby od razu dbał o to, chociażby wciskając enter po każdym nowym komponencie to założę się, że jego IDE samo by mu ustawiło wcięcia.

Potem wziął kod ze stackoverflow i wkleił do projektu. Oczywiście kod nie spełniał oczekiwań w kwestii formatowania. I tu magicznie wkracza Prettier...szybka komenda "format code" i voile'a...ale chwila chwila!...IDE, takie jak chociażby WebStorm, też mają narzędzia do automatycznego formatowania kodu. I też można je wywołać jednym skrótem klawiszowym. To dlaczego mam wybrać Prettiera, który odgórnie narzuca nam sposób formatowania kodu?

Zabrakło mi takich prawdziwych alternatyw. Zamiast tego usłyszałem o spotkaniach, na których toczą się batalie o średniki i taby. Osobiście uważam, że rozpoczynając projekt powinno ustalić się standardy kodowania. Zadecydować o tym czy nasze wcięcia to 4 spacje, 2 spacje a może tab. Wszystkie reguły możemy ustawić np. w eslint, który podpowie nam, kiedy nasz kod nie jest zgodny ze standardem jaki sobie wyznaczyliśmy. Jeśli chodzi o automatyzację to przełącznik --fix automatycznie poprawi nam wszystkie błędy w formatowaniu. Plusem takiego rozwiązania jest to, że dopasowujemy reguły pod nasz styl pisania. Są także opinie, że linter powinien służyć tylko do analizy statycznej naszego kodu np. czy wszystkie argumenty naszej funkcji są wykorzystane, a nie do formatowania kodu.

Jeden rabin powie tak...a drugi powie nie...

Podsumowując - Tomek w swoim stylu opowiedział o Prettier. Widać, że jara się tą biblioteką jak arab na kurs pilotażu. Uważam jednak, że zbyt “agresywnie” ugryzł temat, nie przedstawiając alternatyw, a może bardziej skreślając je definitywnie na starcie. Ale to tylko moja subiektywna opinia i możecie się z nią zgadzać albo mieć ją "w pompie" ;)

Był jeden slide, z którym zgadzam się w 100%. Podczas code-review nie powinniśmy skupiać się na tym czy jest średnik, czy go nie ma...czy argumenty funkcji są długie czy krótkie. Przy code review starajmy się zrozumieć kod, a nie jego formatowanie! Swoją drogą jeśli funkcja ma więcej niż 3 argumenty to bym się poważnie zastanowił czy nie lepiej by było zamienić to na jeden obiekt typu options...ale to inna kwestia ;)


// Tak nie róbmy:
function foo(
  firstArg,
  secondArg,
  thirdArg,
  sum,
  handler,
  onClick
) { ... }

// Lepiej zróbmy tak:
function foo({
  firstArg,
  secondArg,
  thirdArg,
  sum,
  handler,
  onClick
}) {
 ...
}

Różnica tu jest taka że przy długiej liście argumentów łatwo jest się pogubić w kolejności. W przypadku obiektu options nie obchodzi nas kolejność ;)

(+) za poczucie humoru
(+) za wyjaśnienie czym jest prettier
(-) za brak alternatyw
(-) “agresywne” podejście do tematu


Jeśli zabrakło Was na wczorajszym spotkaniu to na stronie Sebastiana na pewno ukażą się (albo już się ukazały ;)) nagrania video i będziecie mogli sami ocenić czy to co napisałem to bzdury i brednie czy rzeczywiście tak było :)

PS. Tomek - mam nadzieję, że nadal będziemy kolegami ;)

Dzięki za uwagę i do zobaczenia na kolejnym meet.js ;)