#инструмент дня

Итак, это свершилось. GreenSock, создатели GSAP — самой крутой библиотеки анимаций на свете — обновили свой хук useGSAP для React.

Зачем он нужен?

Раньше приходилось жонглировать useEffect и useLayoutEffect, учитывать рендеринг на сервере, чистить за собой... ну как-то так:

import { useEffect, useLayoutEffect, useRef } from "react";
import gsap from "gsap";

// for server-side rendering apps, useEffect() must be used instead of useLayoutEffect()
const useIsomorphicLayoutEffect = (typeof window !== "undefined") ? useLayoutEffect : useEffect;
const container = useRef();
useIsomorphicLayoutEffect(() => {
    const ctx = gsap.context(() => {
     // gsap code here...
        }, container); // <-- scope for selector text
    return () => ctx.revert(); // <-- cleanup
}, []); // <-- empty dependency 

С хуком же все очень просто:

import { useRef } from "react";
import gsap from "gsap";
import { useGSAP } from "@gsap/react";

const container = useRef();
useGSAP(() => {
    // gsap code here...
}, { scope: container }); // <-- scope is for selector text (optional)

И по-умолчанию даже пустые зависимости не надо передавать, если не хотите :)

В общем, жить можно было и без этого всего; но мы же любим сахар и когда за нас продумали корнер-кейсы. Демки тоже есть, к слову.

Пользуемся: https://github.com/greensock/react

И видео, как пользоваться этим добром: https://youtube.com/watch?v=l0aI8Ecumy8

#gsap #react

#статья дня

До сих пор не умеешь пользоваться терминалом? Или не знаешь, зачем это вообще фронтендеру?

Джош Камю с большой статьей о том, зачем фронтенд-разработчику уметь пользоваться консолью: https://www.joshwcomeau.com/javanoscript/terminal-for-js-devs/

Отличное руководство для начинающего, надо сказать.

Даже . и .. объяснены :)

#cmd #terminal #бородач

#инструмент дня

Недавно мы вспомнили о крутой фишке мобильных браузеров: атрибуте enterkeyhint для текстовых полей, позволяющем уточнить поведение клавиши Enter на экранной клавиатуре: https://news.1rj.ru/str/htmlshit/2516

Пришло время узнать, какие же еще атрибуты стоит использовать и зачем.

А чтобы не раздувать это на миллион постов (я всё равно так сделаю, но попозже), предлагаю взглянуть на интересный инструмент, позволяющий поиграться всеми возможными атрибутами полей форм на мобильных браузерах разом: https://better-mobile-inputs.netlify.app/

Например, вы знали, что есть атрибут для автоматической вставки одноразового кода, присылаемого по SMS?

Вот он там самый первый пример. Со скриншотами того, как выглядит клавиатура на iOS и Android.

Естественно, присутствуют ссылки на документацию, рассмотрены разные комбинации атрибутов. Особенно порадовал полный список автодополнения. Оно, конечно, редко когда правильно работает (зависит от усилий разработчиков), но уж если работает — то это приятно.

#input #attribute #mobile #tool

#статья дня

Что больше всего бесит в рекламе на сайтах? Почему каждый второй ставит адблоки и прочие ублоки?

Ну, как минимум, назойливость. Во всяком случае, это то, что бесит лично меня. Вторая причина — количество баннеров.

Тем не менее, без рекламы бесплатный веб практически невозможен. Да, кто-то особо гордый скажет: "Я зарабатываю деньги в реальном мире, а не в интернете", но мы его и не спрашивали.

Так, вся эта сопливая подводка к чему, в блоге Google Chrome вышла хорошая статья на тему оптимизации рекламных вставок. Встречайте: https://web.dev/articles/loading-ads-page-speed

Как и в каком порядке размещать баннеры и контент, когда применять и не применять ленивую загрузку, как обновлять вставки. По пути немного про LCP, CLS и асинхронную загрузку.

Если вас в принципе тошнит от самой мысли о рекламе, воспринимайте статью как практическое руководство по производительности сайтов и приложений. Полезно.

#ad #lcp #cls #performance #бородач

#инструмент дня

Пожалуй, только лишь карась на дне не слышал аббревиатур LCP, TTFB, BPP, CLS и так далее. Что их всех объединяет?

А это все метрики производительности веб-проектов. Если вы запускали тот же самый Lighthouse, то наверняка знаете, что на получение 100% влияет очень и очень многое. Так вот.

Сегодняшний инструмент дня это набор сниппетов для Chrome DevTools для визуализации и считывания влияющих на параметры производительности показателей:
https://webperf-snippets.nucliweb.net/

Что забавно, там даже есть сниппет чтобы искать изображения за пределами экрана, у которых не включена ленивая загрузка! Сомнительно, но почему бы и нет...

И, например, имеется код для анализа скорости подгрузки сторонних скриптов и их влияния на ваш сайт.

Прекрасная штука, в общем.

#performance #devtools #бородач

#канал дня

Итак, котаны, вы могли заметить, я довольно редко делаю различного рода квизы, не выкладываю мемы и вопросы с собеседований. Мне немного интереснее общая сторона вопроса, от фишек и базы до личного опыта.

Поэтому тем, кому хочется быть ближе к коду, могу рекомендовать канал моего знакомого — @code_ready

#фишка дня

Короче, рассказываю.

Открываете вы такие ваши девтулзы в Chrome, нажимаете там Cmd-Shift-P (Ctrl-Shift-P) и видите такие панель команд. Ну типа как в Sublime Text, VS Code и прочих ровных редакторах.

И вот там, например, можно сделать скриншот всей страницы, вместе со скроллом, да-да! Просто ищете название нужной вам команды.

А чтобы не теряться и вообще побольше узнать о возможностях девтулзов Chrome, идите сюда: https://www.canidev.tools/capture-full-page-screenshot/chrome

Там много чего такого есть, разбито по категориям. Видео, скриншоты, ссылки на подробности.

#devtools #chrome #бородач

#фишка дня

Как написать timeout на CSS?

Дед, ты упоролся?

Нет. Мне вот буквально вчера это понадобилось.

На дворе 2024 год и я пишу аккордеоны через CSS Grid и transition на grid-template-rows. Вот как-то так: https://codepen.io/alinaki/pen/bGZOprv

Естественно, так можно анимировать и горизонтально, но суть не в этом.

Суть в том, что мне, например, может понадобиться иметь выпадающее меню внутри аккордеона. Хотя почему, например — мне буквально это понадобилось.

Вот только эта техника предполагает, что у меня на контенте стоит overflow: hidden. Как-то неудобненько получается.

Я попробовал выставить слушатель на событие transitionend и выставлять класс is-overflow, но это превратилось в жонглирование статусами и в итоге перестало работать если на аккордионе начинают быстро кликать.

В голову приходит решение с :has. Если у нас имеется открытый дропдаун, можно выставить overflow: visible и красота.

Вот только поддержка всё ещё так себе, хоть мы и не так ограничены в браузерах.

Следующая идея — повесить transition на overflow с задержкий. Но и тут облом, overflow не анимируется.

К счастью, мы не ограничены одними только транзишенами! У нас же ещё и анимации по ключевым кадрам есть!

И тут мы вспоминаем, что keyframes на самом деле являются ни чем иным, как нативными миксинами. Поэтому... давайте уже просто сделаем:

.accordion-inner {
    display: grid;
    grid-template-rows: 0fr;
    transition: grid-template-rows 0.3s linear;
    overflow: hidden;

    .accordion-item.is-active & {
        grid-template-rows: 1fr;
        animation: 0.6s delay-overflow linear;
        overflow: visible;
    }
}

@keyframes delay-overflow {
    from {
        overflow: hidden;
    }
}

Что здесь произойдёт? Очевидно, overflow начнёт свой отсчёт времени с позиции hidden и за 0.6 секунды (нужно выставлять x2 времени или точнее задавать анимацию) перейдёт в visible.

Пруф: https://codepen.io/alinaki/pen/VwRqaXP

Таймаут? Таймаут :)

Причём, это работает с чем угодно.

Пользуйтесь.

#css #trick

#фишка дня

Я, конечно, топлю за максимальную простоту стилей и срезание углов, потому редко использую тег picture для работы с srcset в смысле размеров изображение под разные устройства и экраны. Но есть у него особенности, которые иначе повторить довольно неудобно.

И я говорю о поддержке медиа-запросов в, буквально, атрибуте media.

Одно из них — адаптация изображений для, например, тёмной или светлой темы или для людей, предпочитающих ограничение анимаций на экране.

В первом случае мы заменим картинку дня на картинку ночи, а во втором — гифку на фотографию.

В общем, смотрим иллюстрацию и кодпен: https://codepen.io/alinaki/pen/wvROeaR

И на закуску, универсальный компонент для отзывчивых изображений, Unpic: https://unpic.pics/img/learn/

#picture #media #theme #бородач

#статья дня

Я вестаю и вообще программирую для веба уже пару десятков лет. Ну ок, с перерывами на безуспешное обучение строительству стартовых ракетных комплексов.

И вот все это время основной задачей всех фронтенд-разработчиков, даже когда их так не называли, было центрирование элементов. Если с горизонтальным все кое-как справлялись, то вот с вертикальным постоянно вопросики.

Я видел центрирование таблицами, марджинами, инлайн-блоками, трансформами, флексом, гридом...

А CSS, тварь такая, постоянно подкидывает новые варианты решения проблемы. Как и новые проблемы, впрочем (чего стоит только укладка длинного текста в блок неизвестной ширины).

Короче, к делу. Джош Комо, наш любимый, собрал наконец-то все достаточно современные и бронебойные способы центрирования контента в блоке, на экране и вообще везде: https://www.joshwcomeau.com/css/center-a-div/

Как всегда, статья — интерактивная. Не знаете английского — не беда, за ползунки в примерах можно подёргать и сразу всё станет ясно.

Моё любимое, конечно, это align-content: center; на элемент любой боксовой модели. В принципе, уже вот-вот можно использовать будет.

Всем центрирования, котаны!

#css #center #middle

#фишка дня

Как вы обычно подсвечиваете какой-то конкретный текст в словах?

Ну, например, пишешь ты приложение для изучения языка, и тебе надо подсветить корень слова или там окончание. Или, простите, суффикс.

Наверное, обернёшь кусок текста в span? Ну, пожалуй.

Вот сиди и пиши код, который бьёт текст на отрезки, потом динамически за ними следит, если нужно...

К счастью, скоро будет чуток попроще и логичнее, потому что к нам заезжает Highlight API!

Как следует из названия, это буквально API для подсветки диапазона (Range) символов.

1. Создаём экземпляр Highlight()
2. Подпихиваем его в коллекцию CSS.highlights, в этот момент экземпляру подсветки можно дать некоторое название, по цвету, например, или отрезку слова.
3. В CSS пишем:

::highlight(rangeName) {
  color: #b3b308;
}

4. Вы великолепны.

Пример c иллюстрации и MDN: https://codepen.io/alinaki/pen/OJqdJbw

В FIrefox пока не поддерживается, а в Safari — с 17 версии.

Но это уже очень многообещающе и никаких (вообще) манипуляций с DOM.

Ждем пока появятся библиотеки подсветки кода, основанные на Highlight API, котаны!

Кстати, класс Range очень интересный, надо бы его подробнее изучить.

#css #highlight

#видео дня

Я уже не раз говорил, что видео может сэкономить кучу времени на реализацию уже готовой идеи, будь то анимация по скроллу или просто красивый фон.

Да даже анимацию открытия модального окна можно сделать с помощью видео.

Так вот, Юрий Артюх записал прекрасное руководство по разным аспектам создания и работы видео с прозрачностью: https://youtu.be/Xg6aYfuvRHk

Как и откуда брать? Чем конвертировать? А что с Safari? Как работать в webm и hevc?

Ну и конечно, как имитировать прозрачность и как сделать видео еще меньше, загрузив его с WebGL-маской.

Как всегда прекрасно.

#video #alpha #transparency #webgl #бородач

#заметка дня

Что-то у меня опять ностальгическое настроение.

Три года назад Вадим Макеев выкатил видео о том, как верстали в нулевых и начале десятых: https://www.youtube.com/watch?v=mE1AvBP08Cs

Видео так и называлось: «Флэшбеки олдфага: IE6, таблицы и JS в CSS».

А сегодня мне напомнили о том, что когда-то было модно слушать радио в интернете.

Давайте эти две темы и объединим в ностальгическом порыве.

Поскольку трафик у многих людей в 2005-2011 годах всё ещё тарифицировался помегабайтно или был очень сильно ограничен по скорости, местечковые провайдеры ставили ретрансляторы спутникового радио в локальную сеть. Было такое и у нас и называлось всё это буквально Радио: https://web.archive.org/web/20110226031844/http://radio.sampo.ru/

Я прикладываю ссылку на вебархив, потому что когда-то сервис был открыт для всех, но потом начались тёрки с РАО.

Так вот, это был мой первый проект когда я устроился веб-разработчиком официально, 2009 год.

Как же верстали в 2009 году?

1. Три колонки, aka святой грааль веб-разработки

Естественно, колонки так и назывались: left, right, main. RTL-поддержка? Семантика? О чём вы вообще, это местечковый сервис :)

2. Прибитый футер, это обязательно!

Ты не мог считаться верстальщиком если не умел в прибитый к низу футер.

3. Много свободного пространства и мягкие цвета

Тогда мы, в смысле, веб-разработчики, только-только начали уходить от газетной вёрстки и желания впихнуть всё на свете. Родился Web 2.0 и его пастельные цвета были везде.

4. Абсолютная резиновость!

Адаптивной вёрстки ещё не существовало как явления, но вот мониторы у людей были от 800x600 до 2560x1440. Мы хотели занять всё пространство вообще.

Откройте сайт на ультрашироком мониторе — ну круто же, согласитесь?

Всё не влезло в одно сообщение, продолжаем...

5. Flash для проигрывания музыки.

Никакого тега audio и его API не существовало. Играли флешем.

Я щас в шоке от того, что WebArchive запускает старые SWF на JS-движке. Если бы работали ссылки на музыку, можно было бы послушать!

6. jQuery. Естественно.

Фильтр по жанрам прекрасно работает спустя 15 лет. Ваше React-приложение так умеет? Ах да, ему же максимум 10 лет.

7. Скруглённые уголочки через четыре отдельных элемента.

Никакого border-radius не существовало, окститесь.

8. Лично я в 2009 году открыл для себя DL-DT-DD. Весь список на них построен. Я считал эту находку гениальной.

9. И синие ссылочки. Естественно, синие. Причем, те, что выполняют действие — было принято подчёркивать прерывистой линией.

Наверное, можно что-то ещё рассказать, но уже о технических деталях, аналогично видео Макеева.

Отметьтесь, если интересно ещё 🙂

#nostalgie #tech #old

#фишка дня

TIL что можно получить список всех внутренних страниц браузеров. Ну знаете, этих chrome://flags, chrome://dino, edge://surf.

На самом же деле это всё — about:// страницы, просто переписываются каждым вендором. Попробуйте ввести about://flags.

А вот если ввести chrome://flags в Edge — он превратится в edge://flags. Гордые какие. Brave, кстати, тем же самым занимается.

Ладно, к делу: получить список всех страниц можно через about://about. Возможно, кто-нибудь найдёт там что-то экстраординарное.

Ну и на закуску: слеши можно не писать.

#chrome #edge #firefox #about #url #бородач

#фишка дня

Не только лишь все знают, что одному элементу можно задавать несколько фонов.

Ну, буквально:

.myclass {
  background:
    background1,
    background2,
    /* …, */ backgroundN;
}

А вот чего точно могли не знать, так это что если расположить в углу блока по радиальному градиенту, получатся прикольные завихрения, как на иллюстрации.

Пруф имеется: https://codepen.io/alinaki/pen/zYbbvWr

Всем красоты, котаны.

#css #gradient

#статья дня

Пришло время вспомнить ещё одну статью Ахмада Шадида (Ahmad Shadeed, который не раз всплывал здесь и ещё много раз всплывёт). На этот раз – о важности учитывания высоты в разработке сайтов.

https://ishadeed.com/article/responsive-design-height/

Разработчики часто забывают, что посетители редко используют весь доступный экран. Не только по ширине, но и по высоте. А мода в современных макетах диктует вольготное использование вертикального пространства, но с обязательным условием: “Всё должно влезать в один экран!”. Это, коненчо, бред, но мода есть мода.

Мне не все примеры в блоге нравятся (особенно с модальным окном, я бы предпочёл прокрутку оверлея вместо уменьшения окна), но тему он поднимает важную, хоть и очевидную. Возможно, именно очевидность является причиной, по которой дизайнеры и разработчики игнорируют эту проблему. За деревьями не видят леса — это оно.

Статья есть в переводе на Хабре: https://habr.com/ru/company/skillfactory/blog/524996/

Не забывайте, что макеты должны адаптироваться под пользователя, а не пользователи — под макеты. И выступайте против глупых решений.

#css #html #перевод #бородач

#заметка дня

Одна из самых раздражающих, хоть и по-своему логичных, вещей в CSS — это тот факт, что стили сопутствующих селекторов подключаются в порядке появления в CSS-файле, а не в порядке, определённом, например, классами или атрибутами.

Да, можно верно заметить, что CSS достаточно универсальная штука, селекторами можно выбрать что угодно и как угодно, решается эта проблема специфичностью.

Вот только в случае двух селекторов с одинаковой специфичностью, правила из того, что определены в файле ниже, победят.

Это, кстати, вполне себе одна из причин, почему атомарные классы набирают такую дикую популярность.

Короче, к моей проблеме. Я переписываю "классическое" веб-приложение на React. Таким образом, у меня уже имеется файл стилей, который я хочу использовать как базу. Естественно, я подключаю его в index.tsx:

import * as React from 'react';
import { App } from './App';
import '../src/scss/style.scss';

Мне кажется, с учётом введения вы уже поняли, в чём косяк. Стили, которые я использую в компонентах моего App успешно сбрасываются назад стилями из оригинального style.scss.

Как это победить? Вы не поверите, но в случае Webpack (у меня Rspack, но сути дела не меняет) не нужно ничего дописывать в конфигурации.

Нужно просто импортировать старые стили первыми. Кто бы мог подумать. Как-то так:

import '../src/scss/style.scss';
import * as React from 'react';
import { App } from './App';

Можете расчехлять помидоры, но, думаю, я оказался не один такой. Может кому ещё пригодится 🫠

#webpack #rspack #css

#статья дня

— Да сколько там того фронтенда?

Ну признавайтесь, слышали же хоть раз подобное высказывание, да?

Количество шуток в сторону фронтенд-разработки поражает. Да, не всегда от знающих людей, но тем не менее.

Но вопрос-то остаётся открытым. А в самом-то деле, сколько там того фронтенда? Как посчитать?

И мы сейчас даже не будем затрагивать огромное количество технологий и поддержке разных браузеров и сред, это детали. Они больше говорят о хорошей памяти и наработке опыта, чем о реальной сложности задачи.

Начать можно с простого: а что такое, собственно, UI? В математическом смысле в последнее время пропагандируется что-то вроде: "Интерфейс это функция состояния".

И так и есть: в модных нынче декларативных фреймворках (и в CSS, кстати, тоже) вы определяете состояния, от которых потом строится интерфейс. Разные состояния — разный результат.

Кстати, вот и подошли: а сколько их, этих состояний? Их считали?

Таки да, считали! Вот, например, статья Винса Спилмана о девяти состояниях UI:

Nothing — Пустой элемент
Loading — Загрузка
None — Ничего не вернулось
One — Одна сущность
Some — Коллекция сущностей
Too Many — Сущностей слишком много, нужна пагинация
Incorrect — Ошибка, неуспех
Correct — Успех
Done — Операция завершена

Посмотрите саму статью, там с иллюстрациями и подробнее.

Но даже эта статья не совсем то, что я хотел бы вам сегодня показать. Дейв Руперт пошёл дальше и рассматривает всё более детально.

Состояние курсора, атрибуты, язык, псевдоклассы, псевдоэлементы, фокус, ARIA, размер и положение экрана, режим энергосбережения, выбранная пользователем тема, состояние сети...

В итоге, что-то получается что фронтенда-то того действительно очень много: https://daverupert.com/2024/02/ui-states/

Я настоятельно рекомендую прочитать статью. Она короткая, просто перечисление, но любой чеклист сдачи проекта обязательно будет содержать если не всё, то часть из списка.

Чем раньше вы уложите у себя в голове факт, что делать и учитывать нужно очень много — тем лучше, котаны.

#frontend #ui #state

#фишка дня

Иногда возникает задача поставить перенос строки после строчного (inline) элемента. Без <br/>, без преобразования элемента в блочный.

На помощь приходят псевдоэлементы.

Значение свойства content — «\A» — это Unicode-символ 0x00000A, который, внезапно, являет собой перевод строки.

Ну и чтобы он сработал, нам стоит прямо указать браузеру на необходимость сохранения переводов строк.

Что это даёт? Ну, например, на десктопе можно показать перевод строки, а на адаптиве – убрать его, очистив content. Конечно, это можно сделать и скрытием <br/>, но мы уже решили, что он лишний.

#css #tricks #unicode #after #newline #бородач