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

Например, фильтр выбора товаров в магазине. Есть фильтры по характеристикам в 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/

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

Называется это чудо Sourcegraph Cody https://sourcegraph.com/cody

В бесплатный тариф включён безлимитный inline autocomplete и 200 запросов к чату. Работает все на Claude 3.5 Sonnet и есть расширения для VS Code и JetBrains. Попробовал расширение для Вебшторма - весь функционал, который доступен в Copilot, доступен и тут. UX точно такой же.

Искал возможность попробовать Claude 3.5, т.к. постоянно слышу, что он намного лучше работает для генерации кода, чем Copilot, а тут такая штука доступна ещё и бесплатно.

Сегодня начинается Advent of TypeScript - https://www.adventofts.com/

Каждый день новая задачка по Тайпскрипту в течении месяца.

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

UI выглядит довольно симпатично и празднично, в отличие от того же Advent of Code https://adventofcode.com/, который судя по всему нужно сдавать на перфокартах.

Очень скептически относился к Biome https://biomejs.dev/, но решил все-таки попробовать.

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

При этом линтинг и форматирование на prettier и eslint занимает 28s, а на Biome - 1s 😳

Раз такое дело решил закинуть Biome в свой темплейт для Next.js - https://github.com/artabr/liva-nextjs, заодно и зависимости обновил.

Эти ребята уже много где мелькали со своей «самой большой в мире» библиотекой инпутов, но они не останавливаются и продолжают пополнять библиотеку другими компонентами.

Тут коллекция диалогов. Все сделано на Tailwind. Там еще есть кнопки, слайдеры и попапы.

Но конечно самое полезное - это все равно инпуты (их там 77 штук): https://originui.com/inputs

У меня есть 60 дней чтобы выложить какое-то приложение в Google Play.

Иначе мой аккаунт будет удалён - оказывается, если ты так ничего и не запаблишил в течение года с создания аккаунта, он удаляется. И 25$ не возвращаются 😁

Короче теперь срочно придётся доделывать какой-нибудь пет проект, чтоб не потерять бабки 😂