10 rzeczy, o których chciałabyś wiedzieć na początku nauki frontendu

Hej! Dzisiaj kolejna część z serii 10 rzeczy, o których chciałabyś wiedzieć na początku nauki frontendu. Mam nadzieję, że zaznajomiłaś się z poprzednim wpisem, w którym znajdzie pięć pierwszych rzeczy. Jeśli nie, to część 1. czeka. My natomiast zabieramy się za następne punkty z listy 🙂 .

Jeszcze korzystając z okazji, w imieniu ekipy Frontowiska, chciałabym napisać, że super, że jesteście z nami! I że dostałyśmy tak pozytywny odzew na naszego bloga. Mamy nadzieję, że zostaniecie tutaj na dłużej i wspólnie z nami będziecie poznawać frontend. Polecamy obserwować nas na facebooku, czy dodać się do newslettera, dzięki czemu nie ominiecie nowych wpisów 🙂 .

 

6. Specificity —  specyficzność CSS

Zastanawiałaś się kiedyś, czemu frontendowiec płacze, kiedy widzi w CSS-ie `!important`? Ano, często oznacza to kłopoty, ponieważ jeśli masz nadpisać style, które używają tej właściwości, to będziesz musiała się zapewne napocić. 

Czemu tak się dzieje? Tutaj wkracza znajomość zagadnienia CSS specificity, czyli specyficzność CSS, czy specyficzność selektorów. To waga, która jest aplikowana do danej deklaracji CSS. Determinuje ona, która reguła zostanie zaimplementowana w przeglądarce, co oznacza, że jest również powodem, dlaczego niektóre elementy nie stylują się tak jak chcemy 😉

 

Jak liczona jest waga specyficzności? Zazwyczaj zapisuje się ją w taki sposób:  0 0 0 0. Z tego względu, że posiadamy 4 kategorie specyficzności i odpowiadające im wagi:

•  style inline: <div style=”background-color: yellow;”> – 1 0 0 0
• ID: #nazwa { background-color: yellow; } – 0 1 0 0
• klasa, psedo-klasa, atrybut: .nazwa { background-color: yellow; } – 0 0 1 0
• element: div { background-color: yellow; } – 0 0 0 1

Tak więc przy każdej deklaracji CSS, za każdym użyciem selektora, w zależności od jego typu, zwiększamy jego specyficzność. A co za tym idzie ustalamy, która reguła będzie widoczna.

 

Weźmy sobie przykład. Zobacz najpierw zakładkę HTML, a później kliknij na CSS.

 

See the Pen
Specyficzność CSS by frontowisko (@frontowisko)
on CodePen.

 

Już widzisz, dlaczego to kolor zielony się zaimplementował?

I tu uwaga: !important jest wszechmocny – nadpisuje każdy z powyższych. Stąd osoby na początku nauki frontendu, które nie mają świadomości istnienia specyficzności, często tego używają, żeby szybko nadpisać style. Dzieje się, to też, wtedy kiedy chce się iść na łatwiznę (co nie jest dobrą praktyką :P) albo zagnieżdżeń jest tyle, że próba naprawy tego skutkuje zepsuciem wszystkiego.

 

Więcej informacji znajdziesz w dokumentacji https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity

Umiesz teraz powiedzieć jaką wagę będzie mieć #practice .makes .perfect div > a ? Spróbuj najpierw samej, jeśli jeszcze nie wiesz, każdą deklarację możesz podliczyć na stronie kalkulatora: https://specificity.keegan.st/

 

7. BEM —  Block Element Modifier

Można powiedzieć, że ratunkiem dla nadmiernego nadpisywania styli jest niezagnieżdżanie elementów. Utrzymanie płaskiej struktury CSS sprawi, że kod nie dość, że będzie przejrzysty, to Ty przestaniesz się frustrować niedziałającym CSS-em.

 

Prawdopodobnie najbardziej znaną metodą radzenia sobie z utrzymaniem płaskiej struktury dla CSS-ów jest BEM – Block Element Modifier.

To metodologia nazywania elementów na stronie według ścisłych reguł. Zamiast stylować elementy po typie selektora, wydzielamy sobie blok i to według niego będziemy nadawać klasy reszcie jego elementów oraz odpowiednio nadawać im reguły CSS.

Blokiem, np. mogłoby być menu, elementami jego linki, a modyfikatorem np. jego kolor, czy wyróżnienie.

.menu zamiast, np. ul, header > div

.menu__item a nie, np. li, .item

.menu__item--bold zamiast, np. li.bold

 

Widzisz w jaki sposób odpowiednio oddzielane są elementy i modyfikatory?

Co nam to daje?

• Tworzymy płaską strukturę,
• Możemy łatwo stylować elementy,
• Nie musimy się martwić o nadpisywanie innego elementu,
• Tworzymy re-używalną strukturę,
• Dzięki blokowi zawsze wiemy, gdzie dany element się znajduje w DOM-ie

 

Na początku nauki frontendu BEM może wydawać się skomplikowanym zagadnieniem. Normalnie łatwiej byłoby nam przecież wpisywać klasy elementów, tak jak chcemy. Jednak to podejście sprawia, że trzeba się zastanowić, co jest blokiem, co możemy użyć ponownie itd. Możliwe, że powstanie o tym osobny wpis, póki co zostawiam Was z lekturą, jak zacząć używać metodologii BEM.

 

8. Podejście mobile first

Podejście, które zazębia się trochę z poprzednimi, ponieważ sprawia, że CSS-y są bardziej poukładane i mniej trzeba nadpisywać elementów. W designie często mówi się o strategii mobile-first, jednak chyba mniej o tym słychać jako o podejściu w kodowaniu. Kiedy myślimy o stronie internetowej, zapewne nasze skojarzenia są związane ze stroną wyświetlaną na ekranie monitora na laptopie, komputerze. I kiedy przyjdzie Ci samej wymyślać projekt, pewnie z tyłu głowy będziesz miała układ desktopowy. I to od niego byś zaczęła. Natomiast to właśnie od urządzeń o małej rozdzielności, jakimi są nasze telefony, powinnaś rozpocząć pisanie kodu. Czemu?

 

Powodów jest kilka. Jednym z nich jest to, że dla tak małych urządzeniach układ zazwyczaj jest prostszy. Elementy zajmują najczęściej 100% rozdzielczości, więc nie trzeba kombinować, co, gdzie ustawić. Dodatkowo strony na urządzenia mobilne nie zawierają tzw. wodotrysków. Związane jest to m.in. z tym że strony na telefonie powinny szybko się ładować. Nie ma tutaj akcji na najechanie myszką, czy niektórych zbędnych animacji, które na małych urządzeniach mogłyby nawet źle wyglądać. Co prowadzi nas też do kolejnego punktu. 

 

Wyobraź sobie, że zaczęłaś pisać CSS-y od wersji desktopowej. Elementy nie mają tutaj przeważnie 100% szerokości. Dodałaś marginesy, potrzebne paddingi, może też bordery i animacje. I wszystko fajnie wygląda, do czasu aż nie zaczniesz zmniejszać rozdzielności – najpierw na tablet, później na mobilki. Co wtedy robisz, żeby zaczęło to wyglądać? Najczęściej wtedy „cofa się zmiany” dla kolejnych breakpointów. Wygląda to tak, że nagle wszędzie deklarujesz, np.:

display: block;

padding: 0;

margin: 0;

border: 0;

Czyli tak naprawdę naprawiasz „błędy” nadpisując zerami reguły dodane do wersji desktopowej.  Może dla jednego elementu to nie jest problem, ale co jeśli jest i kilkadziesiąt?

Nasz CSS znacznie się wtedy rozrośnie. Będzie mało czytelny. Waga pliku będzie większa, a czas ładowania jego w przeglądarce może być wydłużony. To doprowadza koniec końców do wolnego ładowania strony. Tego przecież nie chciałyśmy? Widzisz już teraz jakie implikacje mogą powstać? 

 

9. Formatowanie i analiza kodu

Kiedy jednak usłyszysz historie o tym, jak developerzy spędzali godziny na szukaniu błędów (debugowaniu) w kodzie, a okazało się, że zabrakło średnika, to wiedz, że są one prawdziwe. Czasem tak małe rzeczy mogą uprzykrzyć nam życie. Szczególnie dzieje się to na początku nauki frontendu, gdzie nie zawsze wiemy, gdzie szukać lub co dany błąd może oznaczać.

I tutaj ratunkiem są narzędzia developerskie, bez których ciężko sobie wyobrazić życie. Mam tu na myśli:

• Prettier
• ESlint

 

Prettier zajmuje się automatycznym formatowaniem naszego kodu, według ustalonych reguł. Najlepiej jego działanie sprawdza się, pracując z kimś w zespole. Każdy developer ma pewne przyzwyczajenia. Jednak przy pisaniu projektu, ważne jest, żeby utrzymać pewnie standard. Jednakowy dla wszystkich. Za to właśnie odpowiada nam Prettier.

W jego konfiguracji ustalamy, np. czy wcięcia mają być robione tabami, czy może spacjami. Czy używamy pojedynczego, czy podwójnego apostrofu, czy ma tworzyć nawiasy, spacje itd. Same możecie sobie sprawdzić, ile jest opcji do konfiguracji Prettiera. Po zrobieniu tego już nie musimy się martwić, że coś źle wpisałyśmy, ponieważ to narzędzia samo za nas poprawi kod. Dzięki niemu:

• nasz kod będzie wyglądał wszędzie identycznie,
• nikt przy Code Review nie będzie mógł się przyczepić, że formatowanie jest inne,
• zapobiegamy niepotrzebnemu bałaganowi w kodzie,
• skupiamy się na pisaniu kodu, a nie męczeniu się z jego formatowaniem,
• automatyczne formatowanie sprawia, że praca idzie szybciej.

 

Inne zadanie ma ESlint. Linter odpowiada za statyczną analizę kodu, zapobiegając tym samym powstawaniu błędów lub napisaniu podejrzanej struktury w kodzie. Nie formatuje nam on automatycznie kodu, a jedynie znajduje wszystkie potencjalne problemy. Od nas wtedy zależy, czy błąd poprawimy, czy nie. Tak samo, jak Prettier, ma on szereg możliwości do skonfigurowania lub możemy korzystać ze standardowej konfiguracji. Jeśli wybierzemy drugą opcję, to z góry będzie nam narzucał, co będzie nam się wyświetlało jako warning, a co jako error. Tym samym albo otrzymamy jedynie ostrzeżenie w konsoli o problemie lub wyświetli nam się błąd, przez co projekt się nie skompiluje.

 

10. Dokumentacja

Może to wydawać się Tobie oczywiste, jeśli tak jest to super! 😀 Jednak często dla osób, które dopiero są na początku nauki frontendu i zaczynają przygodę z programowania, nie jest to pierwsze źródło wiedzy. Próbują one szukać pomocy na polskich stronach lub wpisywać swój problem do wyszukiwarki. Nie zdając sobie sprawy, że problem może leżeć w niepoprawnym użyciu danego zagadnienia,  metody. 

O tym właśnie informuje nas dokumentacja. I nie martw się, może brzmi strasznie, tak samo, jak czytanie instrukcji do nieznanego nam urządzenia. Jednak o ile instrukcje często pomijamy, bo sami wolimy rozgryźć co i jak, o tyle dobrze napisane dokumentacja powie Ci wszystko, czego potrzebujesz. Znajdziesz tam informacje m.in. jakie parametry są przyjmowane, ich typ, co jest zwracane i to zwykle z przykładami! Dodatkowo poinformuje Cię czy coś dalej jest wspierane, czy może się przedawniło lub jest w wersji niestabilnej. 

Dokumentacja jest też pierwszą rzeczą, jaką developer powinien sprawdzić przed zainstalowaniem jakiejś paczki (pamiętasz z części 1. o menadżerze paczek, prawda?). Jeśli widzisz, że coś tej dokumentacji nie posiada lub jest ona mocno uproszczona i nie za bardzo wiesz, co tam się dzieje, to warto się zastanowić czy to instalować. 

Umiesz z pamięci powiedzieć, co zwraca metoda forEach albo slice w JavaScripcie? Czy addEventListener posiada trzeci parametr? Albo czym różni się object-fit: contain od cover i kiedy się to stosuje? Jak nie, to zapraszam do sprawdzenia w dokumentacji MDN i podzielenia się odpowiedzią w komentarzu! 😉 

 

Podsumowanie

Tym oto wpisem zamykam temat 10 rzeczy, o których chciałabym wiedzieć na początku. Jednak jest to subiektywna lista i właściwie takich rzeczy mogłoby być o wiele więcej.  Zawsze w trakcie nauki odkrywamy coś nowego i potem możemy żałować, że stało się tak późno! Ale to jest w tym też super, bo to znaczy, że się ciągle uczymy i możemy zauważyć nasz rozwój. Dajcie znać, co z tej listy było dla Was nowe, może chcecie żebyśmy rozwinęły któryś z punktów? Co Wy byście dodały do takiej listy 😉 ?