Смогут ли React-хуки заменить компоненты высшего порядка (HOC)?

Перевод статьи Do React Hooks Replace Higher Order Components (HOCs)? с сайта medium.com для css-live.ru, автор — Эрик Эллиотт

«Мандаринка» — снимок Малкольма Карлоу (CC-BY-2.0)

Как только API React-хуков вышел, стало появляться много вопросов о том, сможет ли он заменить другие общие библиотеки и паттерны в экосистеме React+Redux.
Хуки задумывались как замена классам и еще одна прекрасная альтернатива для композиции поведения в отдельные компоненты. Компоненты высшего порядка также полезны для композиции поведения. Очевидно, что их задачи где-то пересекаются, так не заменить ли нам компоненты высшего порядка хуками? Более чем ясно, что некоторые HOC-и они заменить могут. Но нужно ли заменять все ваши HOC-и на React-хуки?

Смогут ли React-хуки заменить Redux?

Перевод статьи Do React Hooks Replace Redux? с сайта medium.com для css-live.ru, автор — Эрик Эллиотт

Вкратце: хуки хороши, но Redux они не заменят

«Мандаринка» — снимок Малкольма Карлоу (CC-BY-2.0)

Как только API React-хуков вышел, стало появляться много вопросов о том, сможет ли он заменить Redux.

Как по мне, хуки довольно слабо пересекаются с Redux. Они не дают никакого нового волшебства для состояний, а лишь улучшают API для того, что уже было в React. Но с API хуков пользоваться нативным React-инструментарием для состояния стало гораздо удобнее, а поскольку он – еще и более простая замена для классовой модели, мне теперь гораздо чаще удается к месту использовать состояние компонента

Чтобы мои слова стали понятнее, давайте сначала разберемся, зачем вообще нам бывает нужен Redux.

Пользовательские CSS-атрибуты как механизм передачи данных из JavaScript в CSS

Перевод статьи Using CSS Custom attributes generated by JavaScript as a handover mechanism с сайта medium.com для css-live.ru, автор — Кристиан Хайльман

Обновление: изначально я слишком упростил, что пользовательские атрибуты не поддерживают конкатенацию, но благодаря Шиме Видасу, Брайану Карделу и Грегу Уитфорту ситуация прояснилась.

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

Фантастические веб-спецификации и где они обитают

Многие разработчики, что уж скрывать, недолюбливают спецификации. Одни считают их скучными. Другим они вообще кажутся монстрами, не иначе как порожденными мифической Ехидной (невероятно, но это отчасти правда: именно так — Echidna — называется система автопубликации, используемая в W3C). Новичка они могут запутать, как лешие, заманить в ловушку, как сирены, и озадачить неразрешимыми загадками, как Сфинкс. Зато о тех, кто проник в их тайны и подчинил себе их мощь, порой слагают легенды фронтенда.

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

Уроки CSSbattle

В начале апреля появилась затягивающая и познавательная онлайн-игра для верстальщиков — CSSbattle.dev. Вашего покорного слугу угораздило «влипнуть» в нее практически с самого начала (и даже пару раз какое-то время побыть в самом топе:). Это был интересный и поучительный опыт, которым хочется поделиться.

CSS и производительность сети

Перевод статьи CSS and Network Performance с сайта csswizardry.com, опубликовано на css-live.ru с разрешения автора — Гарри Робертса.

Несмотря на то, что сайт уже больше десяти лет называется «CSS-волшебство», за последнее время на нём не было ни одной статьи, связанной с CSS. Давайте я это исправлю, совместив две мои любимые темы: CSS и производительность.

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

В чём главная проблема?

Собственно, вот почему CSS так важен для производительности:

  1. Браузер не может отобразить страницу до построения дерева отрисовки;
  2. дерево отрисовки получается из DOM и CSSOM вместе взятых;
  3. DOM — это HTML плюс любой блокирующий JavaScript, который на него влияет;
  4. CSSOM — все CSS-правила, применённые к DOM;
  5. с помощью атрибутов async и defer можно легко сделать JavaScript неблокирующим;
  6. сделать CSS асинхронным намного сложнее;
  7. поэтому важно помнить, что скорость загрузки страницы определяется самой медленной таблицей стилей.

Правильная шпаргалка по CSS-каскаду

Написать эту статью меня подтолкнула относительно недавняя статья на CSS-tricks (скорее всего, вы ее уже видели, ссылку не дам из вредности:). Ее автор проделал большую и замечательную работу — нарисовал красивую наглядную схему-«шпаргалку», написал объяснение простым языком, привел кучу примеров, не забыл даже про презентационные атрибуты, тоже влияющие на стили (в SVG)… Увы, даже та статья подтвердила два печальных правила: 1) никто не знает CSS, 2) никто не читает спецификаций. Так что первая ее редакция транслировала одно из популярных заблуждений о каскаде. К чести автора, он оперативно исправил и схему, и статью — но если бы он заглянул в стандарт, этого могло бы и не понадобиться…

Вот я и решил бесстыже позаимствовать идею простой и наглядной визуальной «шпаргалки» из той статьи — но сразу сделать ее правильной, отражающей не только личный опыт автора, но и стандарт.

Прокачиваем навыки отладки с помощью инструментов разработчика Chrome (часть 2)

Перевод статьи Improve Your Debugging Skills with Chrome DevTools (Part 2) с сайта telerik.com для css-live.ru, автор — Питер Милчев

Chrome devtools

В этой статье мы рассмотрим продвинутые функции отладчика Chrome, закрепив навыки, полученные в первой части.

Вы научились проверять сгенерированный HTML и применённые стили? Уже смело можете отлаживать JavaScript в браузере? Надеюсь, поскольку в этой серии мы рассмотрим продвинутые функции отладчика Chrome, закрепив навыки, полученные в первой части.

Освоив новые навыки, мы поэкспериментируем с базовыми примерами Kendo UI, а в конце статьи возьмём реальный пример jQuery Grid, чтобы отточить на нем свежеприобретенные знания.

Прокачиваем навыки отладки с помощью инструментов разработчика Chrome (часть 1)

Перевод статьи Improve Your Debugging Skills with Chrome DevTools с сайта telerik.com для css-live.ru, автор — Питер Милчев

Chrome devtools

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

Бывали ли у вас неприятности с неверной работой JavaScript? Доводилось ли вам биться с подгонкой стилей элементов на своей странице? Бесит ли вас, когда страницу каждый раз надо тестировать на разных устройствах?

Если ответили «Да» хотя бы на один вопрос, то эта статья для вас. Вот наши полезные приемы и советы, которые помогут вам всё это побороть и повысить вашу продуктивность.

Почему мы не добавим в HTML элемент <чудесный>?

Перевод статьи Why don’t we add a <lovely> element to HTML? с сайта www.brucelawson.co.uk, опубликовано на css-live.ru с разрешения автора — Брюса Лоусона

Вчера был интересный разговор, который начала Сара Суайдан:

твит Сары Суайдан (@SaraSoueidan), 8 октября 2018 г. в 16:36:

Вот что я хотела бы увидеть в HTML:
<color value=“” />
Просто. Чрезвычайно полезно, особ. для дизайн-систем сегодня.

Тут, пока никто второпях не подумал «но ведь цвет — это не контент, а оформление!», Сара говорила о страницах с палитрами образцов цвета. В этом случае цвета — именно контент. Кажется, что это хороший кандидат в семантические элементы, потому что у него есть значение.

На правах Древнего Старожила Веба, я сел и пораздумывал над этим.

Почему семантический HTML важен, и как TypeScript помогает это понять

Перевод статьи Understanding why Semantic HTML is important, as told by TypeScript с сайта medium.com для css-live.ru, автор — Мэнди Майкл

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

Из-за того, что внимание во фронтенд-разработке всё больше сосредотачивается на JavaScript, а про HTML все как будто забывают, недавно мне пришлось потратить какое-то время, пытаясь понять, как объяснить разработчикам, нацеленным на JavaScript, почему важно изучать и понимать HTML

Это натолкнуло меня на идею:

«Почему семантический HTML важен, и как Typescript помогает это понять»

Никто не знает CSS: специфичность — не каскад

Пролог (в котором едва обошлось без драки)

Прошедшие выходные ознаменовались небольшой драмой в веб-сообществе. Началась она с безобидного «теста» по CSS в твиттере Макса Штойбера, разработчика styled-components и react-boilerplate:

Насколько хорошо вы знаете CSS? (эмодзи: ученик у доски)

При таких классах:

.red { color: red; }
.blue { color: blue; }

какого цвета будут эти дивы?

<div class="red blue">
<div class="blue red">

Решено с помощью CSS! Логическая стилизация на основе числа элементов

Перевод статьи Solved with CSS! Logical Styling Based on the Number of Given Elements с сайта css-tricks.com для CSS-live.ru, автор — Юна Кравец

Эта статья третья из серии про мощь CSS.

Все статьи серии:

А вы знали, что CSS — Тьюринг-полный? А что его можно использовать для вполне серьёзной логической стилизации? Можно-можно! И не нужно закладывать логику для стилевых правил в JavaScript, или навешивать скриптом классы, для которых вы задаете стили. Во многих случаях CSS сам справится с этим. Я до сих пор ежедневно открываю новые CSS-трюки, и этим CSS нравится мне всё больше и больше.

Стандарт для нестандартного

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

В какой-то момент оказалось, что такими нестандартными штуками в вебе достаточно активно пользуются. И бедным браузерам, чтобы не вылететь из конкурентной гонки, волей-неволей пришлось худо-бедно эту отсебятину поддерживать. Фактически, она стала стандартом де-факто. И практикам из WHATWG ничего не осталось, как написать для этих нестандартных штук свой стандарт, названный стандартом совместимости (Compatibility Standard). Чем же он нас порадует?

Как мы делали веб-интерфейс для Google Photos: заглядываем под капот

Перевод статьи Building the Google Photos Web UI с сайта medium.com для CSS-live.ru, автор — Антин Харасимив

Несколько лет назад мне посчастливилось стать инженером в команде Google Photos и поучаствовать в их первом запуске в 2015-м. Множество людей вложило силы в этот продукт — дизайнеры, продукт-менеджеры, исследователи и бесчисленные инженеры (в области Android, iOS, веба и серверной части), если упомянуть лишь некоторые важные роли. Я отвечал за пользовательский веб-интерфейс, а точнее, за сетку с фотографиями.

Мы хотели попробовать что-то масштабное и при этом поддерживать раскладку с равномерным выравниванием по всей ширине, сохранять пропорции каждого снимка, сделать интерфейс листаемым (т.е. чтобы было можно перескакивать к любому разделу своего архива), справляться с сотнями тысяч фото, обеспечить скроллинг с 60fps и практически мгновенную загрузку.