Всем привет! В этом канале буду делиться интересными находками на тему фронтенда, Реакта, DevOps, PHP, и всего, что связано с современным вэбом.

Вообщем-то это мои закладки, но я буду рад, если подпишетесь и будете комментировать.

Сегодня вышел релиз кандидат MUI 6.0

Это значительное обновление, которое принесёт “zero-runtime CSS-in-JS” – теперь стили будут рассчитываться во время сборки проекта, что положительно повлияет на перфоманс и позволит удобнее использовать MUI при серверном рендеринге.

В основном такой подход вызван распространением SSR в React и, в частности, React Server Components.
Очень радует, что MUI, которая является наверное самой распространённой и стабильной библиотекой компонентов для Реакт, развивается в направлении северного рендеринга. Все таки перфоманс решает. Даже для админок (а может и тем более для админок).

MUI развивает свою библиотеку для “zero-runtime CSS-in-JS” Pigment CSS, которая является форком уже достаточно распространённой Linaria.

Почитать подробнее про новую архитектуру можно тут: https://mui.com/blog/introducing-pigment-css/

Особое восхищение автора вызывает скорость разработки - 3 часа. Потом правда выясняется, что это чистое время описания инструкций и генерации кода. А перед этим автор потратил 6 недель на проектирование и уточнение деталей (что в моем понимании означает, что он выяснял как лучше сформулировать инструкции).

Конечно приложение это базовый CRUD, кроме того использует функциональный фреймворк. И вообще выглядит так, что знающий человек напишет такое ну не за 3 часа, а за 10-15. В чем преимущество над Copilot пока не сильно заметно. А может с копайлотом и за 8 напишет, там ни требований ни дизайна, как получилось, так получилось.

Проблема в такой сильной интеграции AI будет с тем, что больше времени потом будет потрачено на редактирование кода под реальные требования (и я имею ввиду что время это точно будет потрачено - не важно как, руками вы будете это переписывать, либо промптами). Когда лепишь поделку достойную начальных курсов - выглядит довольно быстро и впечатляюще, но реальный проект внесёт свою сложность и не понятно ускорит Cursor разработку или нет.

Но попробовать Cursor захотелось.

Некорое время думаю над одной задачей. Вернее над оптимизацией текущего решения - отображения списка элементов на основе поиска и фильтра по параметрам. 

Например, фильтр выбора товаров в магазине. Есть фильтры по характеристикам в UI, есть локация пользователя по геопозиции, есть локация пользователя, которую он сам выбрал (и мы её сохранили например в локалсторадж), есть фильтры, которые приходят из query-параметров в URL.

С этими параметрами мы делаем запрос к АПИ, и если ничего не найдено, по хорошему нам лучше показать пользователю другие товары, уменшив ограничения, если это имеет вмысл.
В каких случаях это имеет смысл - например если пользователь сохранил ссылку с нашим поиском, но у нас теперь нет этих товаров - сохранил поиск красных чайников, но теперь у нас нет красных чайников, а есть просто чайники.
Если мы покажем ему пустой поиск, то возможно он просто поменяет фильтры в UI, а возможно просто закроет страницу и уйдёт. Мы этого не хотим, поэтому лучше все-таки что-то показать.
А если пользователь не пришёл по сохраненной ссылке, а просто выбрал фильтры, по которым ничего не найдено. Тогда лучше все-таки показать пустую страницу.

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

Таким образом несмотря на довольно примитивную задачу наша бизнес логика становиться крайне разветленной и асинхронной.

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

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

Поэтому сейчас смотрю в сторону https://stately.ai/docs/xstate

Нужно разобраться будет ли код с xstate читабельнее, и удобнее, чем с другими стейт-менеджерами.

Посмотрел отличный туториал по XState от самого Matt Pocock https://youtu.be/2eurRx-tR-I

Cucumber.js - безусловно одна из самых популярных библиотек для e2e тестирования фронтенд приложений.

Но насколько она популярна, настолько невыносима её документация.

Дело в чем? Cucumber создаёт отчёты после выполнения тестов, при этом отчёты могут быть отформатированы сторонними плагинами. Для этого схема сообщений типизирована в отдельном репозитории https://github.com/cucumber/messages. Можно создать собственный плагин, который будет показывать удобный вам UI с результатами тестов.

Так же, Cucumber можно запускать программно прямо из JS, а не из командной строки. При этом сообщения будут падать в коллбек вызова.

const { runConfiguration } = await loadConfiguration();

const { success } = await runCucumber(runConfiguration, undefined, (message) => {
  console.log("onMessage:", message);
});

Вопрос в том, как отправлять собственные сообщения в этот поток сообщений?

В идеале я бы хотел в step definition отправить сообщение и чтобы оно потом появилось во всех репортах, и в коллбеке вызова.

А по умолчанию там только определённые схемой сообщения.

Расширение схемы сообщений в Cucumber не предусмотрено (по крайней мере я не нашел), но можно добавить вложение в сообщение с выполненным степом.

Оказалось, что Default World констрактор передает метод attach, который позволяет отправлять вложения прямо из степов. Этот метод можно прикрепить к своему Custom World классу и использовать внутри step definitions.

class CustomWorld extends World {
  constructor(options) {
    super(options)
    this.attach = options.attach
  }
}

И потом эти вложения будут появляться в любых нативных репортах Cucumber.

Как всегда этого нет в доке на основном сайте, а запрятано где-то в глубинах их репозитория https://github.com/cucumber/cucumber-js/blob/main/docs/support_files/attachments.md

Вышел новый Next.js 15. Что же в нем нового? Ничего.

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

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

Из других “грандиозных” улучшений - поддержка ESLint 9, индикатор статической страницы в дев моде и поменяли название опции в конфиге, которая отвечает за бандлинг сторонних зависимостей.

Как всегда внушительный прогресс по Turbopack - теперь после этого слова в скобочках стоит Stable. Все также убийца вебпака не поддерживает кастомные лоадеры и лоадеры стилей.

Что действительно интересно - это изменение политики кеширования, и гораздо больше контроля над кэшем для self-hosted систем - https://www.youtube.com/watch?v=sIVL4JMqRfc&t=1429s

Ну и чтобы пользователи окончательно потеряли голову от этого колоссального релиза, в release notes добавили codemod утилиту - раньше не добавляли, хотя codemod был в каждой версии начиная с 6-ой.

Наткнулся на пост в LinkedIn о том, как правильно организовать структуру файлов в Реакт приложении.

Ну типа логику Context API складывайте в папку /context, хуки складывайте в папку /hooks

И вспомнил про довольно продвинутую систему организации, предложенную ещё Дэном Абрамовым.

Вот тут можно почитать доку по ней: https://react-file-structure.surge.sh/