В моем одностраничном приложении, основанном на реакции, моя страница разделена на две панели.
Левая панель: панель фильтров.
Правая панель: сетка (таблица, содержащая данные, которые проходят через применяемые фильтры)
В общем, у меня есть приложение, которое выглядит очень похоже на amazon.com. По умолчанию, когда пользователь удаляет конечную точку приложения (/) в браузере, я получаю последние 7 дней с сервера и показываю его внутри сетки.
Панель фильтров имеет пару фильтров (например, фильтр времени для извлечения данных, которые попадают в указанный промежуток времени, идентификаторы для поиска данных с определенным идентификатором и т.д.) и кнопку поиска, прикрепленную в заголовке панели фильтра. Нажатие кнопки поиска делает последующий вызов на сервер, предоставляя выбранные фильтры внутри тела почтовой формы, сервер возвращает данные, соответствующие фильтрам, и мое внешнее приложение отображает эти данные, возвращенные с сервера внутри сетки.
Теперь, когда кто-то нажимает кнопку поиска на панели фильтров, я хочу отображать выбранные фильтры в параметре запроса URL-адреса, потому что это поможет мне поделиться этими URL-адресами с другими пользователями моего веб-сайта, чтобы они могли видеть фильтры Я применил и увидел данные внутри сетки, соответствующие этим фильтрам.
Проблема здесь в том, что если при нажатии кнопки поиска, я использую http get с параметрами запроса, я закончу приложение для приложения из-за ограничения, налагаемого на длину URL-адресов разными браузерами.
Пожалуйста, предложите мне правильное решение для создания таких URL-адресов, которые помогут мне установить выбранные фильтры на панели фильтров без каких-либо побочных эффектов в моем приложении.
Возможное решение: Учитывая тот факт, что мы не можем напрямую добавлять простые строки в параметр запроса из-за ограничения длины URL-адресов из разных браузеров (Примечание. Спецификация не ограничивает длину запроса HTTP Get, а отличается браузеры реализуют свои собственные ограничения), мы можем использовать что-то вроде дайджеста сообщений или хэша (конвертировать ввод произвольной длины в вывод фиксированной длины) и сохранять его в БД для сервера, чтобы понять запрос и обслуживать контент. Это просто мысль, я не уверен, является ли это идеальным решением этой проблемы.
Поведение других сильно используемых веб-сайтов:
- amazon.com, newegg.com → использует хешированные URL-адреса.
- kayak.com → , поскольку у них есть очень четко определенные ключевые слова, они используют короткие формы, такие как IN for INDIA, BLR для Bangalore и т.д. и объединяют это с логикой отрицания для дальнейшей оптимизации максимальной длины URL-адреса. Не но это будет идеально ломаться после большого выбора фильтров.
- flipkart.com → присоединяет строки непосредственно к параметрам запроса и разрыву после того, как предел нарушен. подтвердил это.