Недавно создатель библиотеки nuqs написал интересную статью по мотивам доклада о нюансах сохранения стейта приложения в URL. Оказывается, с этим подходом не всё так просто. Вот что говорится в статье:

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

Другой неочевидный плюс — time travel, когда браузерные кнопки "Назад" и "Вперёд" становятся похожими на Redux DevTools. Но пользователи этот плюс не оценят: браузерная кнопка "Назад" создана для навигации, а не для отмены введённого значения в поле выбора сортировки товаров. Изменение привычного поведения кнопки "Назад" только всех запутает и выбесит))

Теперь о минусах

• Сложность в типизации и сериализации. Придётся писать костыли как при чтении из URL, так и при записи в него.

• Ограничение скорости записи. Chrome и Firefox позволяют обновлять значение в URL не чаще, чем 1 раз в 50 мс, Safari — 1 раз в 120 мс. Сразу представляем, как мы пишем дебаунсы на текстовые инпуты или, что ещё хуже, на input type="range".

• Длина ссылки. Современные браузеры спокойно принимают URL длиной в 2000 символов и более. Но вообще весь этот пост занимает около 2400 символов. Вы бы кликнули на ссылку, если бы она была размером с целый пост в тг?

• Иммутабельность. Вот добавил пользователь себе в закладки вашу ссылку — и всё, теперь вам придётся всю жизнь поддерживать ту структуру стейта, которая была актуальна для вашего приложения на тот момент. Если захотите переименовать какие-то поля или изменить структуру, придётся писать адаптеры.

• SEO. Поисковики могут проиндексировать несколько ссылок на одну и ту же страницу с разным набором query-параметров и пометить их как дубликаты, что ухудшит положение сайта в поисковой выдаче. Не забываем пользоваться link rel="canonical".

Мои мысли мои скакуны)))0 Да, и статья, и доклад были призваны продемонстрировать, как nuqs помогает побороть все эти проблемы. В nuqs есть куча парсеров, врапперов и других инструментов, демонстрацию их использования можно посмотреть в самом видосе.

Но мне кажется, всех этих проблем можно избежать, если хранить в URL только самый минимальный набор данных, который просто парсится и который вы готовы предоставить пользователю. Тогда никакие библиотеки с парсерами не понадобятся. А то люди до сих пор не избавились от qs.

Хорошо, что автор nuqs открыто говорит, что не стоит хранить в урле всё подряд.