Какое состояние стоит хранить в URL и как защищать маршруты?
- Зачем хранить фильтры в URL?
- Как сделать приватные маршруты?
В URL хранят то, что должно переживать перезагрузку, делиться ссылкой и работать с кнопкой «назад»: фильтры, сортировку, страницу, открытую вкладку, поисковый запрос. URL становится источником истины — компонент читает параметры, а меняет их через навигацию. Защищённые маршруты: родительский маршрут или loader проверяет авторизацию и перенаправляет на вход с параметром возврата; настоящая проверка прав — всегда на сервере, на клиенте — только удобство.
- Значения из URL валидировать (Zod) и иметь значения по умолчанию
- Частые изменения (ввод поиска) — с debounce и replace, чтобы не засорять историю
- Временное состояние интерфейса (открыт ли выпадающий список) в URL не нужно
А ещё Скрытая кнопка не защищает данные — защищает API
Подробно
function RequireAuth() {
const user = useUser();
const loc = useLocation();
if (!user) return <Navigate to={`/login?next=${encodeURIComponent(loc.pathname)}`} replace />;
return <Outlet />;
}Что хотят услышать
- Что хранить в URL и почему.
- Валидация и replace.
- Защищённые маршруты и проверка на сервере.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Скрытие маршрута на клиенте надёжно защищает данные, серверная проверка прав не нужна
- ✗В URL стоит хранить всё состояние интерфейса, включая открытые подсказки и наведение
- ✗Значения из URL можно использовать без проверки, ведь их формирует само приложение
- ✓Фильтры и страницу — в URL ради ссылок и «назад»; права всё равно проверяет сервер
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.