Ладно, буду сюда закидывать.
Там зафлужено
🍏

https://orm.drizzle.team/

Мне нравится этот маркетинг)))

Если пишете backend на Rust, а фронт на React

https://www.rspc.dev/

Выкидывайте redux! На сцену выходит zedux!

https://omnistac.github.io/zedux/blog/zedux-is-this-the-one

В поезде прочитал интересные размышления от François Zaninotto — Is React Having An Angular.js Moment?

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

И вот у нас React предлагает поменять парадигму и перейти на Server Components. И это опасное место.

Теперь наши компоненты уже не просто рисуют отображение по состоянию. Они становятся сложнее. Теперь прямо в компонентах мы можем использовать fetch не заворачивая его useEffect. И это не браузерный fetch, это патченая его версия. Зачем патченая? Для того, чтобы бороться с лишним ре-фетчем данных и обложить всё кешами из коробки. А кешировать забрасывая данные в контекст мы больше не можем — нет в серверных компонентах контекста.

Вообще useState, useContext и useEffect — все они не работают. Мы можем их включить, используя use client, но это теперь не поведение по умолчанию.

CSS-in-JS решения тоже пока не работают в серверных компонентах. (Тут я конечно немного радуюсь, что «классические» решения всё так же хороши).

С отладкой тоже пока не очень, но тут наверное допилят (должны допилить!).

Экосистемы для RSC просто нет. Знакомые нам либы не работают (react-query, swr, react-hook-form и т.д.). Короче, всё, что на хуках.
Если они нам нужны, то мы должны заворачивать всё в обёртки с use client.

Почти всё сломано. А ещё и контекст отобрали, как теперь лёгкий DI пилить?

И запросы на сервер странные. Формат намеренно не документирован.

Разработчикам SPA всё это не нравится. Они обеспокоены. Для SSR они готовы брать другие решения. Почему Реакт отговаривает от SPA? Почему официальная документация рекомендует Next, а Next рекомендует RSC? Может быть это способ помочь Vercel заработать на React? Ведь для RSC нужен бэкенд, а бэкенд нужно где-то запускать.

Но отвечая на заглавный вопрос проходит ли React свой «момент Angular» автор говорит — нет, не проходит. Потому что мы всё ещё можем писать «по-старому». Без Server Components.

Но в то же время пользователи теперь вынуждены выбирать между старым рабочим решением и новым сияющим активно рекламируемым. И это опасно. Между двух альтернатив выбора может возникнуть третья — иной фреймворк. И вот тут React вполне может нанести вред своему сообществу. Зачем мне RSC, с той же долей риска я могу перейти на Solid или ещё куда-нибудь.

В заключении Франсуа призывает команды React и Next одуматься и притушить рекламный поток для RSC. Не выпячивать это решение как противовес «классике» и единственное возможное будущее, чтобы не навредить экосистеме React.

Роутер в Nextjs

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

Но спустя время я хочу заявить, что стало в разы сложнее:
pages/shop/[foo]/[...bar]
притом, что есть еще pages/another/[[...catch]].
Но я вижу в проектах еще и директории именующиеся со скобками /(some)/ и даже /@example/.

Недавно, я потратил минут 20 на попытки выяснить, почему я не могу сделать pages/api.mdx, притом, что вываливалась максимально невнятная ошибка.

А теперь, я вижу, что не только у меня возникают такие ощущения. Вот эта статья набирает популярность, где понятным языком, с помощью визуализации другие разработчики объясняют как работает роутер.

Не значит ли это, что идея файлового роутинга не прошла проверку временем и является полностью провальной?

https://www.builder.io/blog/layouts-in-nextjs-13-visual

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

Весьма показательно количество бенчей, методология замеров, а также детальное описание подхода.

https://github.com/dmonad/crdt-benchmarks

Просто рядовое напоминание, что бенчмаркинг это сложная наука!

Моё любимое кафе в Ереване организует митап.
Дизайн, фотография, текстиль, визуал.

Уже в эту субботу!

Сторис! Дамы и господа

Интересный взгляд на ИИ

Сначала статья показалась мне слишком банальным страхом. Но вчитавшись, я получил новый источник размышлений

Передозировка useMemo

Разработчики склонны злоупотреблять useMemo и даже не могут адекватно объяснить, почему они это делают. В своем блоге Эдвин Антонов поделился мнением по поводу того, когда стоит использовать useMemo. Если кратко:

- Сначала профилируйте, потом оптимизируйте. Профилируйте сначала производительность, чтобы выявить узкие места, а потом оптимизируйте компонент.

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

- Следите за тем, чтобы зависимости useMemo были точными.

https://edvins.io/usememo-overdose

Да. Я снова собираюсь смотреть

Сейчас пишу библиотеку для работы с таймлайнами и обнаружил крайне интересное поведение JEST.

Jest считает два этих снепшота идентичными… чет у меня подгорает.

Я пишу довольно сложный код, а тут такая подстава от инструмента тестирования

Пишу редюссеры на 120 строк.
А потом смотрим Apple Event

Через 25 минут смотрим презу и заполняем бинго-лотерейную табличку.

Насколько кринжово будет в этот раз. Или не будет? 🤔 📱

У меня есть привычка немного волонтёрить в чатах с новичками, потому что бывает такое, что мне самому нужна помощь по работе.

Но проблема в том, что 99%(оценочное суждение) вопросов выглядят как: "я вот написал код, он должен работать, но не работает". И почему-то люди не умеют обрабатывать такие ситуации.

Поэтому вот вам инструкция, как решать такие проблемы:
1. найдите 100% рабочий по вашему мнению кусок кода, который можно безболезненно удалить из программы
2. Удаляйте его
3. Смотрите результат.
Если программа стала работать как вы ожидаете, то проблема в удалённом вами фрагменте. Постарайтесь вынести этот кусок кода в отдельный модуль и возвращайтесь к пункту 1.
Если программа продолжает работать не так как вы ожидаете, то значит, что непонятка осталась в неудалённом коде. Возвращайтесь к пункту 1 и продолжайте пока не найдёте проблему.

В итоге после этого цикла у вас есть маленький кусочек кода, в котором есть проблема.

Если вы поняли в чём проблема, то супер. Исправляйте её, покрывайте тестами, так как другие люди не хуже и не лучше вас. Помогите им в будущем. Плюс PR станет читать куда проще.
Если вы не понимаете в чём проблема, то выносите этот пример в какую-нибудь песочницу, к примеру, в http://jsfiddle.net и только ПОСЛЕ этого идите в чат за помощью.
Ваши скриншоты огромного полотна редко когда помогают найти проблему. А вот код, с которым можно поиграться и поэкспериментировать - вполне.

Как говорится: формулирование проблемы - это половина решения проблемы.