Следите ли вы за новостями фронтенд-разработчиков в последнее время? Будьте в курсе наших новостей за октябрь 2022 года о выборке данных, запросах контейнеров CSS и наших мыслях о CSS-in-JS.

командой инженеров Whitespectre

Получение данных в React

Выборка данных в React может сбивать с толку. Существует бесконечное количество библиотек управления данными, Suspense называется решением, но это все еще экспериментально, и недавно было указано, что загрузка данных внутри useEffect имеет некоторые подводные камни:

  • Сетевые водопады: вместо параллельной загрузки данных иногда вы можете непреднамеренно ждать, пока все вышеперечисленные родительские компоненты закончат выборку, прежде чем запустится дочерний компонент.
  • Нет кеша: если вы вернетесь на страницу, вы получите ее снова, если только вы не используете библиотеку или не запрограммируете какую-либо пользовательскую логику кэширования.
  • Нет рендеринга на стороне сервера: эффекты не запускаются на сервере, поэтому вы не сможете предварительно визуализировать какой-либо полезный контент, если используете SSR.
  • Условия гонки и утечки памяти: если вы не напишите функцию очистки, вы можете в конечном итоге создать ошибки при установке состояния с ответами, которые приходят в другом порядке или просто в компонентах, которые больше не монтируются.

Значит ли это, что мне нужна библиотека? Ну да. И нет.

Если вам не нужен SSR или кеширование запросов, а ваше приложение не настолько сложное, чтобы возникала проблема с водопадами, useEffect вполне подойдет. Дело не в том, что его нужно запретить внезапно, просто разработчики React хотят, чтобы вы подумали о том, как выбор архитектуры повлияет на UX и производительность вашего приложения.

Сказав это, есть кое-что, о чем вам определенно нужно позаботиться, если вы извлекаете данные с помощью useEffect, и это последний пункт в списке выше: написание функций очистки. При выполнении любой асинхронной операции в целом убедитесь, что вы игнорируете устаревшие или прерываете запросы на выборку с помощью AbortController.

Игнорировать устаревшие асинхронные операции:

Вы можете использовать следующий хук: useAsyncEffect. Он инкапсулирует пример в документации React и работает с любой асинхронной операцией. Атрибут ignore.current будет истинным, если функция очистки запущена, т. е. эффект устарел или компонент размонтирован.

Из справки API React Hooks:

«Если компонент рендерится несколько раз (как обычно), предыдущий эффект очищается перед выполнением следующего эффекта»

Отменить устаревшие запросы на получение:

Следующий хук — хороший пример: useFetchWithAbort. Он основан на том же принципе, что и предыдущий, но специфичен для fetch запросов и использует AbortController для эффективной отмены запроса на очистку.

Если вы хотите глубже изучить предотвращение состояний гонки и утечек памяти с помощью useEffect, взгляните на «Исправление условий гонки в React с помощью useEffect» от Max Frozen.

Если вы заботитесь о производительности и хотите узнать больше о сетевых водопадах, ознакомьтесь с этим: Как получить данные в React с учетом производительности от Нади Макаревич.

Запросы контейнера CSS

Для контейнерных запросов еще рано, но с выпуском Safari 16.0 в прошлом месяце они уже поддерживаются в Safari (Webkit) и Chrome (Blink), а это означает, что Edge (Blink) скоро последует. Firefox, вероятно, тоже не отстает.

Как вы, наверное, знаете, с помощью Container Queries мы можем выбирать стили, основываясь на размере элемента контейнера, а не только на размере браузера:

.posts {
  container-name: posts;
  container-type: inline-size;
}
.post {
  display: flex;
  flex-direction: column;
}
// This style will not apply if posts container is >= 600px
@container posts (min-width: 600px) {
  .post {
    flex-direction: row;
  }
}

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

// If posts container has white background, make .post color gray
@container posts (background-color: #fff) {
  .post {
    color: #444;
  }
}

Style Queries не являются частью первоначальной реализации Container Queries, которая только что появилась в Chrome и Safari. Тем не менее, они являются частью Стандарта W3C CSS Containment, и Chrome предоставил экспериментальную поддержку с пометкой функция.

Чтобы быть в курсе последних новостей о поддержке браузеров и углубиться в эту тему, взгляните на эту статью от Bramus или послушайте CSS Podcast Episode 59 от Una и Adam!

Проблемы и преимущества CSS-in-JS

CSS-in-JS — это новая парадигма, которая штурмом захватила пространство фронтенд-разработки. Он набирает обороты с тех пор, как появились основанные на компонентах JavaScript-фреймворки, такие как React, Vue или Angular, но всегда вызывал споры.

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

При использовании CSS-in-JS стили связаны с компонентом. Изменения стиля компонента не будут иметь неожиданных последствий, и если компонент будет удален, то же самое произойдет и с его стилями CSS.

Однако у этого подхода есть и важные недостатки, которые стоит учитывать, и Сэм Магура написал об этом отличную статью Почему мы расстаемся с CSS-in-JS.

Вы найдете довольно подробную разбивку преимуществ и недостатков CSS-in-JS с тестами и подробным анализом влияния на производительность. Наконец, он объясняет решение, которое они придумали: Модули CSS (в данном случае написанные на SASS). Вдумчивый анализ всей парадигмы, безусловно, стоит взглянуть!

И, говоря о CSS, ежегодный опрос разработчиков о последних тенденциях CSS уже открыт! Примите участие в опросе State of CSS здесь!

Что бы вы хотели добавить? Думаете, чего-то не хватает? Пишите нам в @whitespectrehq, Instagram или LinkedIn, мы будем рады прочитать ваши отзывы!

И не пропустите наши предыдущие истории: