Autor: Radek Anuszewski

Wprowadzenie

A po co ograniczać ilość event listenerów? Powodów jest kilka:

1. Szybsze budowanie się UI. Mniej listenerów do podpięcia to po prostu mniej kodu do wykonania. To także często mniej operacji na DOM – aby podpiąć listener do elementu musimy przecież pobrać go np za pomocą querySelector.
2. Płynniejsza obsługa UI. Mniej listenerów to mniej nasłuchiwania, szczególnie jeśli np w podpinamy bardzo dużo eventów mouseenter/mouseleave do np tabelki.

W jaki sposób możemy więc ograniczyć ilość listenerów? To zależy od sytuacji, ale jeden ze sposobów może być wykorzystany nader często – mianowicie podpinanie listenerów na rodzicu zamiast na poszczególnych elementach.

W tym artykule porównamy szybkość podpinania listenerów w 2 przypadkach – gdy podepniemy jeden listener to całej tablicy a także gdy podepniemy listener do każdego przycisku w wierszach tablicy. Tablicę wypełnimy tysiącem wierszy z których każdy będzie miał 1 przycisk do usunięcia tego wiersza.

Czytaj dalej „Sprawdź jak ograniczyć ilość event listenerów w JS!”

Spis treści

1. Wprowadzenie
2. Kod bazowy dla porównania ImageCapture vs canvas
3. Robienie zdjęcia
   1. Stary sposób z canvas
   2. Nowy sposób z ImageCapture
4. Wsparcie ImageCapture
5. Kod przykładu na Github
6. Klikalny przykład na Github Pages
7. Podsumowanie

Wprowadzenie

We wszystkich aplikacjach WWW w których pracowałem do tej pory robienie zdjęcia polegało na podpięciu się do wideo z kamery i przechwyceniu pojedynczej klatki strumienia. Klatka ta była potem rysowana na elemencie <canvas> a następnie zapisywana jako blob.

To podejście jest hakiem, wymaga nadmiarowych elementów. Niedawno natknąłem się na dedykowane przeglądarkowe API ImageCapture, opisane m.in. na Mozilli. Pozwala ono zrobić zdjęcie w znacznie prostszy sposób, bez elementów pośrednich i obejść.

Sprawdźmy więc czym różni się nowe podejście od starego.

Czytaj dalej „Sprawdź jak dzięki ImageCapture zrobisz zdjęcie prościej w swojej aplikacji”

Spis treści

1. Wprowadzenie
2. Notka o modułach
3. Obecny sposób obsługi plików
   1. Implementacja
   2. Niedogodności
4. Nowy sposób obsługi plików z File System Access API
   1. Implementacja
   2. Wątpliwości dotyczące File System Access API
5. Kod przykładu na Github
6. Klikalny przykład na Github Pages
7. Podsumowanie

Wprowadzenie

Kiedy ostatnio spojrzałeś w katalog plików pobranych na Twoim dysku? Czy przeszukiwanie go zawsze jest koszmarem, z ogromną ilością duplikatów i plikami nazwanymi w taki sposób: somefile.txt, somefile (1).txt, somefile (2).txt, somefile (2) (1).txt itd.

Jeżeli miałeś przyjemność pracować na dokumentach do których zmiany dodaje kilka osób to praca wygląda często tak:

1. Pobierasz plik somedocs.txt bo chcesz coś dodać
2. Wpisujesz ważne rzeczy i wrzucasz na Slacka/Teamsy.
3. Ktoś doda zmiany, pobierasz plik i trafia on do katalogu Pobrane, ale ma nazwę somedocs (1).txt żeby nie nadpisać obecnego pliku
4. Wrzucasz, ktoś bierze pliczek, znowu coś dopisuje
5. Pobierasz, tym razem ma nazwę somedocs (1) (1).txt
6. Robi się nieporządek

I jestem w stanie wymienić bez zastanowienia sytuację, gdy spotkałem się z takim namnażaniem się chaosu 🙂 Mianowicie:

Pliczek z pytaniami do rekrutacji – nie chcesz by ten plik był dostępny dla wszystkich, by współpracownicy nie wrzucali go swoim znajomym aplikującym do firmy w której pracujesz, a fajnie mieć plik z którego możesz brać pytania.

Na szczęście pojawia się API, które pozwoli nam zapanować nad chaosem – File System Access API. Pozwala ono między innymi na zapis plików na dysku z wyborem nazwy – w analogiczny sposób jak zapisują pliki natywne aplikacje.

W tym poście porównamy obie wersje.

Czytaj dalej „Obsługuj pliki lepiej dzięki File System Access Api”

Spis treści

1. Wprowadzenie
2. React Portals
3. Alternatywy dla React Portals
   1. React Context
   2. React Redux
4. Kod przykładu na Github
5. Klikalny przykład na Github Pages
6. Podsumowanie

Wprowadzenie

Portale w React są funkcjonalnością, na którą natkniesz się prawdopodobnie na samym końcu – po przekopaniu całego internetu w poszukiwaniu rozwiązania. Renderowanie zawartości w innym miejscu niż logicznie element należy wydaje się nie mieć sensu – pomaga jednak rozwiązać problemy z z-index czy overflow na jakie możesz natknąć się przy próbach wyświetlenia treści. Choć Portal niekoniecznie będzie pierwszym wyborem – często może okazać się znacznie szybszym rozwiązaniem niż refaktor lub inne bardziej oczywiste opcje – poznajmy więc jak one działają.

Czytaj dalej „React Portals i podejścia alternatywne”

Spis treści

1. Wprowadzenie
2. Wyświetlanie powiadomień
   1. W jakim momencie można wyświetlać użytkownikowi powiadomienia?
   2. Jak nie być natrętnym z wyświetlaniem powiadomień?
   3. Kod przykładu na Github
   4. Klikalny przykład na Github Pages
3. Podsumowanie

Wprowadzenie

Pokazywanie powiadomień jest przydatne w wielu sytuacjach – idealnym przykładem są czaty, gdzie w oczekiwaniu na odpowiedź drugiej strony możemy zająć się czymś innym niż gapieniem się w ekran 🙂

Dodatkowo, w przeglądarkach opartych na Chromium powiadomienia wyglądają i zachowują się jak notyfikacje systemowe, co dodatkowo podnosi ich atrakcyjność i przyciąga uwagę bardziej niż zwykłe powiadomienia przeglądarkowe. Na Windows 10 powiadomienie takie odtwarza dźwięk, dzięki czemu będzie łatwiej zauważone przez użytkownika.

Czytaj dalej „Notifications API – powiadomienia jako sposób nawiązywania relacji z użytkownikiem”

Spis treści

1. Wprowadzenie
2. Przykład w React
   1. Sposób liczenia rerenderów
   2. Kod przez refaktoryzacją
   3. Kod po refaktoryzacji
   4. Kod przykładu na Github
   5. Klikany przykład na Github Pages
3. Podsumowanie

Wprowadzenie

Podczas pracy zawodowej zdarzało mi się doświadczać sytuacji, gdy pracując pod presją czasu trzeba było iść na “kompromisy” jeśli chodzi o jakość kodu. Z czasem w projekcie używającym Reacta pojawiały się komponenty typu “wielotysięczniki”, które miały setki a czasem nawet tysiące linii kodu. Im dłużej trwał development, tym więcej kodu dolepiane było do takich komponentów oraz rosła ich liczba zależności.

Gdy zaczęliśmy przerabiać takie olbrzymy na mniejsze komponenty, nieco zaskakującą korzyścią był spadek ilości rerenderów. Po zastanowieniu się, okazało się to proste i oczywiste – zarządzanie stanem, również przeniesione do różnych komponentów, powodowało rerendery tylko tych komponentów w których było zawarte.

Czytaj dalej „Sprawdź, jak prosty refaktor może zredukować liczbę rerenderów w Twojej aplikacji!”