допустим SPA на реакте с hash роутером
что ты подразумеваешь под политикой навигации?

1. Рабочий вариант, если база быстро поднимается. 2. Вот тут есть риск что 5-й тест как-то неправильно поломает данные, которые потом будет использовать 37-ой тест. 37-й упадёт и вы будете долго искать почему он упал. 3. Вполне рабочий. Есть такой приём - при старте теста открыть транзакцию, в конце абортировать -база вернется в исходное состояние. Применить можно не всегда - зависит от логики вашего приложения.

Ты, похоже, не понимаешь, как все устроено. Логику все равно писать. Автоматом на бек запрос при переходе по url не пробросится. Более того, использовать два одинаковых uri для фронта и бека не получится

Я хочу добавить, что трансляция параметров напрямую - это еще и небезопасно

я понимаю как оно устроено, я понимаю что логику отправки запроса и спа всё равно писать, я не понимаю ЗАЧЕМ при этом менять в фильтрах что-то что можно не менять

воот, вот это похоже на ответ, к этому я и веду

А как они в запрос на бэк попадут без доп обработки? Гудвин их подставит?

В каких фильтрах?

Или Мерлин

Просто никто не делает фильтры для спа. Их делают для отправки на бек

Блин. криво звучит)

Узбагойся, менять не обязательно. Ты уходишь от изначального своего вопроса. Мы уже поняли что гет и пост разные запросы, причем семантика?

Опять таки при пост у тебя уйдет в теле запроса и тут без логики ты не конвертируешь из url

нет не ухожу, я из раза в раз перезадаю его меняя формулировку ближе к контексту обсуждения в надежде что так будет проще понять

тип запроса(get и post) это тоже атрибут запроса, и я спрашиваю зачем мне может потребоваться поменять этот атрибут(или любой другой) при обработке данных из url внутри SPA если я могу этого не делать? я знаю что сохраение типа запроса не даст мне гарантии что запрос от клиента к вебсерверу с spa и запрос от spa к беку будут иметь одинаковый тип, но изменение типа запроса это действие, которое по умолчанию можно не делать, дак зачем мне всё же может понадобиться его сделать?

ну мне вариант использования видится так: сохраняешь урл с применёнными фильтрами в закладку в браузере и при переходе по нему у тебя всегда будет открываться страница с применёнными фильтрами

я верю что так мало кто делает, но не верю что это никому никогда не было нужно

Так ты про запрос по загрузке фронта или по запрос к бэку?

Так делают и очень часто

Капец, это я днем еще спросил про гет/пост и до сих пор идет обсуждение)

Ну

про оба, они разные и у них обоих есть атрибуты, в том числе тип запроса, я могу при перегонке данных из запроса на загрузку фронта в запрос к беку поменять всё что угодно но зачем мне менять тип запроса и поле в котором хранится фильтр если я могу этого не делать

кстати, я вспомнил пример когда такое необязательное действие библиотеки создало мне проблемы

библиотека fetch(все её реализации на момент когда я этим занимался) при отправке запроса преобразует имена хедеров к нижнему регистру, а на беке аутентификация(не помню какой конкретно компонент, давно это делал) требует хедер с id сессии c большой буквы из за этого я не смог использовать fetch и не смог настроить его чтобы он не трогал имена хедеров и мне пришлось отказаться от него

и казалось бы по стандарту допустимо что fetch кастует имена хедеров к нижнему регистру а нарушает стандарт именно бек обращая внимание на регистр в регистронезависимых именах хедеров, но если бы fetch не выполнял это необязательное действие он был бы совместим с беком