сервис поиска отдаёт id элементов, которые похожи по соответствию, эти id я клал в query url next.js и редиректил на другую страницу, чтобы показать результаты поиска. Данные для query запроса брал из url параметров страницы. Появился такой кейс, что при большом кол-во элементов которые вернул сервис по поиску, падает приложение с ошибкой 414, у nginx видимо ограничение.
Одно из решений, я просто при получении от сервиса id пихаю их в cache react-query через setQueryData и на странице поиска получаю эти данные, считается ли это за хорошую практику? Норм вообще так делать? Или я костылю?
вроде норм но 414, судя по википедии – не ограничение NGINX. почитай внимательно
Нашёл инфу, спс
ну вы слишком длинный url запроса передаете там есть какое то ограничение, в общем вроде 8k символов (вроде) ну и если такая ситуация, то одно из решений преедавать этот массив через post запрос а не get
при таком решении разве нет проблемы чтое если пользователь обновит страницу то ничего не увидит?
а кеш react-query хранится не в памяти?
а нельзя данные на основе которых получаются id-шники положить в квери?)
Ну в данный момент ничего не пропадает, он по идее при перезагрузке страницы запросит новые данные с сервера, но ничего не получит, думаю что оставит прошлые данные
с чего оставит и откуда
незнаю что за кейс коенчно, но если пользователь при обновлении страницы не получает ту же страницу - звучит как плозой UX
Id может быть много, боюсь что потом при получении большого кол-ва id и если класть их в query next выкинет ошибку из-за 414.
так не id класть, а те данные на основе которых эти id получаются
можно для данных сгенерировать ключ - хеш или ууид, и с этим ключом положить данные в localStorage, при редиректе передавать этот ключ параметром, и по ключу доставать из локалсторидж обратно
Так не получится У меня мутация, которая отправляет post запрос на сервис поиска, а этот сервис отдаёт эти id
почему это мутация?)
Обсуждают сегодня