#ссылка дня

"The journey of the React Component" — "Путь компонента в React", буквально — вот так незамысловато называется интерактивный проект Алекса Сидоренко: https://alexsidorenko.com/react-journey

Его цель — провести вас по всем основным процессам, происходящим во время рендера компонента, включая хуки. На данный момент рассмотрен только useState, но начинание уже очень крутое. Кому-то, возможно, будет понятнее, чем чтение статей и исходников React.

Правда, я не сразу понял, что где-то можно кликать, а где-то нет... 😅️️️️️️ Но то такое.

#react #render #tutorial

#заметка дня

Cегодня буду краток. Стал забывать, что у многих +1 час к моему времени.

Я часто вижу в профильных чатах вопросы типа: «Помогите, истерика, текст не занимает всю ширину контейнера и мой флексбокс не работает!»

Короче, происходит ситуация, как на картинке: кажется, что место справа никак не используется.

Ладно бы только начинающие такое спрашивали, но нет же. У всех дыры и паника, паника и дыры.

А суть в том, что рендер текста — это сложно. Рендер длинных слов — это очень сложно.

Потому браузер всегда выделяет для текста максимально возможную ширину. Неважно, ограничили ли вы её условиями флексбокса или установили max-width. Возьмёт всё и начнёт упихивать буквы и слова. Как сможет.

Пример расчётов можно посмотреть в серии статей Инлайновый контекст форматирования, раздел «Горизонтальное выравнивание».

Подсказка: он не сможет. И выделенное место не вернет.

А люди ожидают, что текст спокойно сдвинется вправо и у чекбокса будет больше воздуха. К сожалению, так не получится вообще никак.

Единственно, кажущееся разумным, решение — это заполнить всю предоставленную ширину, используя переносы (словарь или ­). Ну или word-break: break-all;

Есть ещё не очень разумные решения с использованием JavaScript для подсчета реально занимаемой ширины.

Вот три примера: https://codepen.io/alinaki/pen/ExrGRwL?editors=1100

Не паникуйте, ну.

#css #flex #render

#заметка дня

Я часто вижу в профильных чатах вопросы типа: «Помогите, тут истерика, текст не занимает всю ширину контейнера и мой флексбокс не работает!»

Короче, происходит ситуация, как на картинке: кажется, что место справа никак не используется.

Ладно бы только начинающие такое спрашивали, но нет же. У всех дыры и паника, паника и дыры.

А суть в том, что рендер текста — это сложно. Рендер длинных слов — это очень сложно.

Потому браузер всегда выделяет для текста максимально возможную ширину. Неважно, ограничили ли вы её условиями флексбокса или установили max-width. Возьмёт всё и начнёт упихивать буквы и слова. Как сможет.

Пример расчётов можно посмотреть в серии статей Инлайновый контекст форматирования, раздел «Горизонтальное выравнивание».

Подсказка: он не сможет. И выделенное место не вернет.

А люди ожидают, что текст спокойно сдвинется вправо и у чекбокса будет больше воздуха. К сожалению, так не получится вообще никак.

Единственно, кажущееся разумным, решение — это заполнить всю предоставленную ширину, используя переносы (словарь или ­). Ну или word-break: break-all;

Есть ещё не очень разумные решения с использованием JavaScript для подсчета реально занимаемой ширины.

Вот три примера: https://codepen.io/alinaki/pen/ExrGRwL?editors=1100

Кстати, если кому реально интересно как работают алгоритмы Flexbox (вы же не думали, что это изобретение только для CSS? Во Flutter тоже они) есть прекрасная статья по поводу: https://tchayen.com/how-to-write-a-flexbox-layout-engine

Не паникуйте, ну.

#css #flex #render #бородач

#видео дня

Вдогонку к посту про алгоритмы работы движка Flex-раскладки, позволю себе обнаглеть и приложить ещё и это видео: https://www.youtube.com/watch?v=RVnARGhhs9w

Называется буквально "How to render in WebKit".

Да, ему 10 лет, но 10 лет назад Flex уже был сформирован и даже прошли споры по первой версии Grid. Там определённо есть что почерпнуть.

На правах закладки, ага :)

#render #webkit

#статья дня

Насколько глубокая вложенность элементов влияет на производительность вашего проекта и влияет ли вообше?

Вот Google Lighthouse утверждает, что влияет. Но так ли это на самом деле?

Коннор проверит

Как хорошо, что у нас теперь есть на это ответ: https://frontendatscale.com/blog/how-deep-is-your-dom/

TL;DR:

1. Ощутимая разница начинается на 500 элементах: плоский список рендерится в два раза быстрее вложенного.
2. Далее расхождение растёт практически линейно и на 5000 элементах мы уже наблюдаем 800 мс для вложенного против 180 мс для плоского. Впрочем, это вырожденный случай.
3. И всё бы ничего, но до этого момента всё обсуждение велось для скелета без стилей, точнее, со встроенными браузерными. Набрасываем ещё немного CSS — и к этой прелесть добавляется 150 мс. Что уже может быть совсем заметно глазу.

Вместо вывода:

Да, 5000 вложенных элементов это редкость, но многие дизайн-системы и UI-киты построены вокруг максимально простой структуры Stack-Row-Col-Element, заставляющей вас создавать лишнюю вложенность. Таких комбинаций на странице могут быть тысячи.

Сама по себе вложенность не является чем-то плохим, но она задаёт базу для пересчёта стилей и JS-операций над DOM, поэтому иногда на это стоит обратить внимание.

#render #performance

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

На видео — не высокохудожественный глитч, а результат работы очередного нового рендер-трекера для React: React Scan.

Очевидно, натравленный на Твиттер

Репозиторий: https://github.com/aidenybai/react-scan

Чем хорош: не нужно кодить! Ну, если только ты сам не хочешь :)

Импортируем перед реактом и просто запускаем анализ:

import { scan } from 'react-scan'; // import this BEFORE react
import React from 'react';

scan({
  enabled: true,
  log: true, // logs render info to console (default: false)
  clearLog: false, // clears the console per group of renders (default: false)
});

Естественно, это не всегда нужно. Как только нашли проблемный компонент на большой картине — обернули его в withScan и дебажьте себе на здоровье.

Хороший инструмент, хоть и в начале своего пути. Мне бы очень хотелось видеть расширение для Chrome, чтобы вообще ничего не настраивать.

#react #render #devtools

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

Итак, помните пример современного глитч-искусства на примере Твиттера?

Ну я про React Scan, который показывает число ререндеров на странице, вот: https://t.me/htmlshit/3285

Парни выпустили CLI-утилиту, чтобы можно было просканировать любой сайт! Да-да, они обещали расширение для браузера, но пока так:

npx react-scan@latest <URL>

...и поехали.

Что-то резко стало охота завтра на работе шороху навести на корпоративном портале.

#react #render #devtools