Jak już wielokrotnie wspominałem GraphQL mnie w pewien sposób zauroczył na tegorocznym FrontendCon. Zauroczył mnie tak bardzo, że postanowiłem się tym chwilę pobawić. Stąd też mam zamiar napisać małą serię dotyczącą tego rozwiązania w miarę postępu moich zabaw. Dziś chciałbym zacząć od podstaw czyli czym jest GraphQL oraz jak można rozpocząć zabawę z nim.

Jak już kiedyś wspominałem w poście dotyczącym testowania(znajdziecie go tutaj) testowanie jest ważnym elementem podczas tworzenia oprogramowania. Dziś chciałbym poświęcić chwilę czasu na testy jednostkowe w React’cie. Testy jednostkowe powinniśmy tworzyć dla właściwie każdego komponentu dzięki czemu będziemy mieć pewność, że działa poprawnie i niczego nie psujemy podczas zmian lub ulepszania kodu.

Podejrzewam, ze większość z was jak nie wszyscy spotkali się z Markdownem. Jeśli nawet osobiście nic w nim nie pisaliście to widzicie jego efekty w 90% repozytoriów na githubie w postaci plików Readme. Warto co nieco o nim wiedzieć, ponieważ w łatwy sposób można z jego pomocą upiększyć swoje repozytorium.

SCSS jest tym dla CSS czym Typescript dla JavaScript’u. Pozwala nam w prosty sposób rozszerzyć możliwości zwykłego CSS . Natomiast BEM jest zbiorem zaleceń dotyczących tworzenia i nazewnictwa klas. I obie te rzeczy idealnie ze sobą współpracują.

Yarn jest nowym lepszym menadżerem pakietów dla npm. Ile razy słyszeliśmy takie rzeczy? W świecie frontendu średnio raz na tydzień wychodzi nowe lepsze narzędzie, które, jak przekonują nas twórcy, zmieni oblicze programowania. I jak często okazuje się, że po tygodniu zwyczajnie o nim zapominamy bo pojawiło się coś nowego? Więc pewnie zadajecie sobie pytanie czemu zawracam sobie głowę pisaniem o czymś co pewnie zniknie. Ponieważ on nie zniknie tak szybko.

Czy spotkaliście się kiedyś z określeniem Bus Factor? Jest to tak zwana miara ryzyka wynikająca z informacji oraz umiejętności niedzielonych pomiędzy członkami zespołu. Innymi słowy jest to liczba osób jakie muszą zostać „przejechane przez autobus” by nie dało się kontynuować projektu. Jak rozumieć Bus Factor? Wyrażenie „przejechane przez autobus” nie należy brać dosłownie. Oznacza ono dowolny losowy przypadek, który może sprawić, że ważna osoba w projekcie zniknie.Załóżmy na przykład, że mamy super ważny, duży projekt którym zajmuje się 10 osób w tym 4 osoby odpowiedzialne za front, 4 odpowiedzialne za backend I 2 osoby odpowiedzialne za utrzymanie całej infrastruktury serwerowej.