Сова пишет…
856 subscribers
95 photos
12 videos
145 links
Rustacean, Frontender, Podcaster.
Рассуждаю о фронтенде, разработке на Rust, пишу подкаст и стараюсь улучшить этот мир.

https://buymeacoff.ee/sergeysova
Download Telegram
to view and join the conversation
Кто готов купить MacBook Pro M1, куплен в январе, месяц назад менялось всё железо с топкейсом?
Anonymous Poll
15%
100K
85%
Не куплю
This media is not supported in your browser
VIEW IN TELEGRAM
Единственный способ быстро установить react-router со всем необходимым
Ребят, это началось
This media is not supported in your browser
VIEW IN TELEGRAM
Мне одному кажется, что такой способ демонстрации экрана впринципе не может быть удобным?
По мотивам обсуждения статьи про критерии реактивности, я записал выпуск подкаста "Под куполом" — Почему бенчмарки лгут.

anchor.fm/under-a-dome/episodes/ep-e18l0hg

Все платформы, где можно послушать здесь:
podcast.ru/1553479345
Вопрос-наброс. Я токсичный?
Anonymous Poll
27%
Да, слишком
49%
Иногда
24%
Нет
В react-router@v6 нельзя управлять роутером за пределами React контекста.

Источник: github.com/remix-run/react-router/issues/8264

Ryan Florence предлагает вызывать все необходимые действия через useEffect и useNavigate. То есть вернуть контроль внутрь React. Всё было не так плохо, если бы не полная невозможность передать контроль СТМ в режиме SSR, ведь там useEffect не выполняется.

И как справедливо было отмечено, проблему это не решает вообще никаким образом.
Аналогичное issue просто закрывается с предложением передать метод navigate внутрь вашего СТМ.

Но я не смог найти этот метод в API Reference.

А в гайде по серверному рендерингу, написано только краткое: вот неполный список вещей которые вам нужно обрабатывать — стратегии загрузки данных.

Лично для меня это выглядит как издевательство и полное отсутствие заботы о своих пользователях.
Если посмотреть на API базового роутера, конечно вы не увидите здесь history.

А всё потому, что разработчики распилили обычный history на несколько объектов. Теперь history реализует интерфейс Navigator, который в свою очередь можно описать как-то так:

export declare type Navigator =
Omit<History,
| "action"

| "location"
| "back"
| "forward"
| "listen"
| "block">;

А нашел я это поискав по исходникам

На самом деле обращаться можно, но придется реализовать свой BrowserRouter, например вот так:
https://gist.github.com/longdog/aab331660652b397415b7ebae8b77a5d

Но! Придется учитывать особенности работы react18 с его concurrent mode и strict effects, о чем я ещё напишу (как сам разберусь), но человеку без опыта эта задача может оказаться просто непосильной.
К чему я всё это вообще писал?
Я хотел показать на примере (и это уже не в первый раз), как можно сделать больно множеству людей сразу.

Давайте рассмотрим правильный способ выпускать мажорные версии популярных библиотек и сразу разберемся почему это правильный способ, а не просто моё мнение.

Вброс:
1. Все новые фичи должны выпускаться в минорных релизах.
2. Мажорные релизы должны только удалять устаревшие фичи, помеченные таковыми 2 мажорных релиза назад.

Обоснование:
Давайте рассмотрим самый обычный релизный цикл без следования этим двум правилам:
1.0 — вводим фичу A
1.1 — вводим фичу Б
2.0 — удаляем фичу А
2.1 — вводим фичу Д (чтобы не путать с алфавитом ABC)

Теперь, пользователи библиотеки вынуждены переписать своё приложение на новое API, чтобы получить фичу Д.
А если версия 1.x больше не поддерживается, то они обязаны это сделать, чтобы получать обновления безопасности.
А если библиотека имеет peerDependencies, то они также обязаны, чтобы обновлять другие свои зависимости.
Если библиотека серьезно ломает совместимость (как react-router много раз), то рефакторинг может серьезно затянуться и тем самым остановив получение обновлений безопасности, вынуждая использовать костыли, вроде yarn resolutions.

Как правильно:
А теперь, что будет если следовать этому правилу:
1.0 — вводим фичу А
1.1 — вводим фичу Б
2.0 — вводим фичу Д (которая по сути должна заменять фичу А) и депрекейтим фичу А
3.0 — удаляем фичу А

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

В сложных библиотеках/фреймворках есть roadmap и migration guide, который частично снижает боль. На мой взгляд, 2 мажорных релиза, один из которых вешает депрекейты это отличный компромисс между полной обратной совместимостью java и react-router.

Я должен отметить, что новые фичи обязаны не перекрещиваться своим API со всеми существующими ДО этого API в предыдущих версиях, иначе получится проблема обновления через несколько версий:

Пользователь был на версии 1 в которой метод назывался navigate и принимал 2 аргумента.
В версии 2, метод задепрекейтили и удалили в версии 3.
А уже в 4 версии добавили метод с названием navigate, но с другим смыслом и набором аргументов.

Если пользователь будет обновляться с 1 версии сразу на 4, то он может попасть в ситуацию, когда метод navigate в javascript не бросает исключений, он просто тихо и спокойно работает, но работает совершенно не правильно.

За инсайт спасибо @ZeroBias

Любите своих пользователей 🧡
Я слегка упоролся и решил выложить весь список актуальных проектов и своих выступлений

https://projects.sova.dev

А ещё, во вторник подъедет новый выпуск 307 пакетов!
А пока мы ждем новый подкаст с моим участием, проходите почитать полезнейшие статьи и проекты, которые я собрал для вас.

В этот раз много статей про Rust, но JavaScript разработчикам не стоит расслабляться!

https://news.sova.dev/issues/7-850973
А давно Google Flights пишет сколько кг выбросов произведет самолет?
аааааа
Кто из подписчиков живёт в Европе?
Или собирается поехать весной?
Anonymous Poll
17%
Я живу в Европе
7%
Собираюсь в поездку весной
14%
Собираюсь в поездку в другое время
62%
Не живу в Европе