Kulisy powstawania mojej strony

Po kilku miesiącach projektowania, kodowania i pisania, w końcu opublikowałem moją stronę.

Usługi

UI/UX Design, Frontend Development, Tworzenie treści, DevOps

Klient

Ja

Rezultaty

Design system, Strona internetowa, Portfolio, Blog, Newsletter

Linki

Rekurencja

Problem

"Szewc bez butów chodzi" czy może "web developer jest offline". Pomimo że naukę frontendu zacząłem jakiś czas temu, nigdy nie stworzyłem strony dla siebie. Czułem syndrom oszusta i myślałem, że nie jestem wystarczająco dobry. Ale w ten sposób, mógłbym to odwlekać w nieskończoność. Postanowiłem to zmienić. Chciałem mieć swój kącik w internecine - gdzie mógłbym wyrazić siebie i dzielić się moimi znaleziskami.

Szkice

Łatwiej jest zacząć z długopisem i kartką.

Mając to w pamięci, zacząłem generować pomysły. Zrobiłem zgrubne szkice każdej ze stron.

Nie jest to poziom szkiców Da Vinciego, ale były przydatne zanim zabrałem się za robienie makiet.

Wireframes

Wireframes powinny znajdować się pomiędzy szkicami, a prototypami o wysokiej szczegółowości. Nie przejmując się za bardzo fontami i kolorami, zrobiłem wiele takich makiet.

Kolory

Na wyborze kolorów spędziłem więcej czasu niż chciałbym przyznać. Ale po wielu godzinach poszukiwań (i testowania dostępności) doszedłem do porozumienia sam ze sobą. Paleta kolorów powinna być minimalistyczna, prosta, składać się z odcieni bieli i szarości. I oczywiście powinna zawierać niebieski akcent. Nie stoi za tym jakaś filozofia - po prostu lubię niebieski.

Typografia

Chciałem, aby strona była zorientowana na typografię, więc kolejny kawał czasu spędziłem poszukując odpowiednich fontów. Moim celem było zestawienie nowoczesnego fontu bezszeryfowego z bardziej klasycznym szeryfowym. Potrzebowałem także fontu do fragmentów kodu.

Design system

Mając podstawy i część treści, zacząłem tworzyć system projektowania. Chciałem, aby był elastyczny, spójny i łatwo skalowalny. Stworzyłem abstrakcyjne, prymitywne elementy takie jak przciski i nagłówki. Wykorzystałem je w wielu różnych kontekstach do zbudowania bardziej złożonych komponentów i sekcji.

Panda CSS to biblioteka CSS-in-JS, która pozwala na definiowanie bazowych stylów wraz z wieloma wariantami konkretnego komponentu. W ten sposób, definiujemy bibliotekę komponentów, z której przyjemnie się korzysta. Poniżej pokazalem jak powyższy przycisk wygląda w kodzie (ograniczyłem style do tych bazowych, ponieważ oryginalny kod jest długi na 300 linii).

Definiowanie przepisu na przycisk w Panda CSSTSX
1import { cva } from '@/styled-system/css'
2import { sharedTransitionProperties } from '../../utils'
3
4export const button = cva({
5  base: {
6    display: 'inline-flex',
7    alignItems: 'center',
8    gap: 's',
9    padding: 's',
10    fontFamily: 'heading',
11    fontWeight: 'medium',
12    letterSpacing: 'wide',
13    textDecoration: 'none',
14    transitionProperty: 'background-color, color',
15    ...sharedTransitionProperties,
16    cursor: 'pointer',
17    _disabled: {
18      cursor: 'not-allowed',
19      pointerEvents: 'none'
20    },
21    '& > span': {
22      flexShrink: 0
23    }
24  }
25  variants: {
26    // Button variants like primary, outline, etc.
27  },
28  defaultVariants: {
29    // Chose default variants when button is used without any
30  },
31  compoundVariants: [
32    // Compound variants allow for more complex logic
33  ]
34})

I tak - style są definiowane w TypeScripcie. Nietypowe, ale bardzo wygodne. NIe musisz nawet pamiętać swoich design tokenów - autouzupełnianie ci pomoże.

Mając elementy, komponenty i sekcje, stworzyłem responsywne szablony dla każdej strony.

Mój design nie jest skończony i bardziej przypomina proces. Cały czas go rozwijam. W związku z tym możesz zagrać w "znajdź różnicę", pomiędzy tymi szablonami, a aktualną wersją mojej strony.

Zauważyłem, że elastyczność jest pożądana podczas całego procesu. Podobnie jak przerwy - dają nową perspektywę. Nowe pomysły przychodziły do mnie w różnych etapach procesu i w nieoczekiwanych momentach. Jak pomysł na pasek postępu - znalazłem go przeglądając internet. Tak, ukradłem go i się tego nie wstydzę!

The only art I'll ever study is stuff that I can steal from.

— David Bowie

Gatsby

Do zaimplementowania mojej strony użyłem generatora stron statycznych - Gatsby. Strony są budowane i optymalizowane w procesie generowania, nawet zanim użytkownik ich zażąda. Strony internetowe stworzone przy pomocy tego podejścia są zwykle wydajniejsze niż tradycyjne rozwiązania jak WordPress.

Jeżeli strony są generowane wcześniej, skąd wiedzieć jaki motyw wybrał użytkownik? Zaimplementowanie funkcjonalności zmieniania motywów było dla mnie niespodziewanym wyzwaniem. Ale po przeczytaniu o procesie budowania i testach udało mi się zrobić, aby działało to gładko.

Next.js

Słyszy się, że "jeżeli coś działa, to nie ruszaj". Pomimo, że poprzednia wersja mojej strony działała całkiem nieźle, to działanie nad nią stawało się coraz trudniejsze. Dlatego przemigrowałem mój stos technologiczny. Głównie dlatego. Była to też niezła okazja do nauki czegoś nowego, dlatego Next.js stał się moim nowym frameworkiem. On także bazuje na Reac'ie, więc nie musiałem uczyć się wszystkiego od zera. Jednakże, oba te narzędzia różnią się znacznie. Gatsby oferuje bogaty ekosystem pluginów. Myślisz o jakiejś funkcjonalności i najprawdopodobniej istenie na to wtyczka. Jest to jednak broń obosieczna. W łatwy sposób możesz dodać funkcjonalność, ale zaczynasz mieć problem, gdy któryś z pluginów przestaje być wspierany. W Next.js, więcej rzeczy musisz implementować ręcznie. Musisz mieć lepsze pojęcie o tym co robisz, ale daje ci to elastyczność i łatwiejsze zarządzanie w przyszłości.

Testowanie

Poza manualnymi testami, napisałem zautomatyzowane testy. Użyłem frameworka Jest do testowania komponentów. Do testowania integracji pomiędzy komponentami i bardziej złożonych zachowań użytkownika, wykorzystałem framework Cypress wraz z cypress-axe. Te testy pokrywały różne aspekty strony - dostępność, internacjonalizację, SEO i więcej.

Przemigrowałem także zestawy moich testów E2E, wykorzystując Playwright. Oferuje on parytet funkcjonalności w stosunku do Cypressa, a nawet więcej. Nie będę może poświęcał tu wiele czasu na wyjaśnianie różnic pomiędzy nimi, bo napisałem post, który je porównuje - Playwright vs. Cypress - porównanie frameworków do testowania E2E.

GitHub

Będę się starał dodawać treści i funkcjonalności regularnie, dlatego długotrwała konserwacja była celem od początku. Uruchomiłem ciągłą integrację wykorzystując akcje GitHub, aby zminimalizować liczbę błędów i zyskać więcej pewności co do mojego projektu. Każda zmiana w kodzie uruchamia serię weryfikacji i testów.

Playwright, w domyśle, uruchamia testy równolegle, więc mogłem znacznie uprościć moją akcję GitHub CI. Aktualnie jest to jeden job z konfiguracją zbliżoną do tej domyślnej od Playwright'a.

Używam konwencji Conventional Commits do formatowania wiadomości i GitHub Flow jako strategię rozgałęziania.