3 pojęcia widmo web developmentu #2

Sto lat świetlnych temu napisałam artykuł 3 pojęcia widmo web developmentu #1. Najwyższy czas na część drugą.

Dla tych, którzy nie wiedzą o co c’mon z tymi pojęciami widmo – już wyjaśniam. Chcę po prostu podzielić się najbardziej anty-popularnymi terminami związanymi jakkolwiek z web developmentem. Wiadomo, wszyscy piszą o tych modnych frazesach np. w kontekście rozmów rekrutacyjnych. Pójdźmy więc pod prąd rozmawiając o tym, co w ogóle nie jest znane, a często – ani trochę przydatne.

Trickling

Sprawdziłeś to słowo w słowniku? Ja też!

trickling
cieknięcie, kapanie, ściekanie, z wolna napływanie,
powolne gromadzenie się (np. o grupie ludzi).

diki.pl

Eeeee mi ta definicja też niewiele pomogła. Wpisanie hasła „trickling web development” do googli również okazuje się bezowocne! Wobec tego spieszę z wyjaśnieniami.

Trickling to po prostu inna nazwa dla capturing, czyli pierwszej fazy tzw. mechanizmu event propagation. Nic dodać, nic ująć, prawda?

Propagację zdarzeń opisałam już w artykule na temat Event.stopPropagation vs Event.stopImmediatePropagation. W telegraficznym skrócie wyjaśnię Tobie, o co chodzi, jednak mimo wszystko zachęcam do odwiedzenia powyższego artykułu. Mechanizm propagacji zdarzeń w JS (event propagation) opisuje sposób przechwytywania zdarzeń (click, keypress, submit).

Owy mechanizm event propagation składa się z 3 faz:

1. capturing = TRICKLING

• przechwytywanie i wywoływanie napotkanych event handlerów danego typu w kierunku od Document do elementu, który wywołał zdarzenie
• rzadko wykorzystywana
• włączasz jej detekcję za pomocą elem.addEventListener(…, true), elem.addEventListener(…, {capture: true}) lub onClickCapture (React)

2. target

• wywołuje się, kiedy mechanizm propagacji dochodzi do elementu docelowego, który wywołał zdarzenie
• nie posiada własnego handlera, sposobu detekcji, jest wywoływana zarówno dla handlera fazy capture, jak i fazy bubble

3. bubbling

• powrót od elementu wywołującego zdarzenie do Document; przechwytywanie i wywoływanie napotkanych event handlerów danego typu
• domyślnie aktywna
• włączasz jej detekcję za pomocą elem.addEventListener(…) lub onClick (React)

Trisomorphic Rendering

Pozwólcie, że nie będę kaleczyć języka polskiego koślawo tłumacząc to pojęcie. Zostawmy je w spokoju, nazywając po prostu trisomorphic rendering.

Wchodzimy na grząskie grunty wyboru architektury aplikacji, a konkretnie sposobów jej renderowania. Z pewnością wiesz, że aplikacja może być renderowana na serwerze (SSR), albo na kliencie (w przeglądarce – CSR). Możesz połączyć zarówno SSR, jak i CSR, a możesz równie dobrze serwować statyczną stronę wizytówkę. Pewnie też znasz pojęcie service workerów – proxy między siecią a przeglądarką.

A czy wiesz, że zestaw SSR + CSR + service worker nazywa się trisomorphic rendering?

Trisomorphic rendering to technika renderowania. Zakłada wykorzystanie SSR do renderowania first load, czyli pierwszej, początkowej strony, na którą wchodzimy w aplikacji. Dalszą nawigację po aplikacji przejmuje klient, czyli przeglądarka. Service worker wchodzi w grę zaraz po instalacji, zapisując i aktualizując w pamięci podręcznej różne komponenty, szablony, skorupkę aplikacji (generalnie co chcemy). Dzięki niemu mamy wrażenie aplikacji SPA przy renderowaniu kolejnych widoków.

Czy Tobie też ten opis kojarzy się z aplikacjami progresywnymi? Wydaje mi się, że możemy stwierdzić: zasady tworzenia PWA bazują na trisomorphic rendering. O aplikacjach PWA pisałam już wcześniej na blogu.

Więcej informacji na temat trisomorphic rendering znajdziesz na stronie google dla developerów.

Scroll jacking (Scroll hijacking)

Dosłownie – porwanie scrolla.

Umówmy się tak – pewnych rzeczy nie powinno się dostosowywać do własnego widzimisię. Np. weźmy taki kursor. Jeśli zmienimy go na gifa z fajerwerkami – zrobimy naszej stronie duże ała. Generalnie, wśród społeczności developerów, uważa się takie zachowanie za antypattern. Zgadza się, czy nie?

Podobnie sprawa wygląda ze scrollem. Jest on integralną częścią przeglądarki. Tak samo, jak widok zakładek, adresu URL, czy przycisku wstecz. I jakoś nie przeszkadza nam różnorodność ich look & feel wśród tabunu dostępnych przeglądarek (no chyba, że nazywają się IE). A ten scroll, nieszczęsny scroll, okazuje się dla nas wielkim, brzydkim pryszczem na naszej dopieszczonej co do piksela stronce. Tak być nie może, ja, wielki developer, tego tak nie zostawię! Decyzja zapadła – edytujemy go. Tylko troszkę, tak delikatnie. I właśnie owa niewinna zmiana jego wyglądu, zachowania, animacji – nazywa się scroll jacking. I jest bardzo, BARDZO kontrowersyjna.

Jednocześnie samo pojęcie jest słabo znane w polskim internecie. Dlatego też trafiło na moje zestawienie pojęć widmo.

Ze scroll jacking mamy do czynienia (chyba) zawsze w przypadku stron budowanych w stylu parallax. Jednakże jest to jedna z niewielu sytuacji, kiedy porywanie scrolla wydaje się uzasadnione. Ogólna zasada niezmiennie brzmi – nie należy nadużywać tego mechanizmu.

Manipulacje na scrollu są grubą rysą na użyteczności. Użytkownik (o ile ma lat więcej niż 3), jest przyzwyczajony do pewnych zachowań strony. Nagła, nieoczekiwana, nieprzewidywalna dla niego zmiana działania kluczowych elementów przeglądarki (np. scroll) skutecznie odwraca jego uwagę od treści strony. A nie o to nam chodzi!

To nie jest jednak tak, że ten biedny scroll jest nie do ruszenia. Pisałam już na blogu, że za pomocą CSS jesteśmy w stanie naprawdę sporo zdziałać w temacie zarówno wyglądu scrolla, jak i jego zachowania.

Przykład strony z porwanym scrollem znajdziesz tutaj. Źródła: cuberis.com, brunch. A na medium znajdziesz analizę kilku przypadków scroll jacking’u.

Znaliście te pojęcia? Zaskoczyły Was? Piszcie w komentarzach