Closed Zodiase closed 6 years ago
Simply reading location.search
in search result item component doesn't work since they won't get an update to re-render when location is changed.
This means the props passed to the search result item component need to react to search state changes or simply location
changes.
Passing FlowRouter
queryParams
all the way into the components doesn't work since FlowRouter doesn't pickup location
changes made by SearchKit. Also the component that renders all the result items, <Hits>
, doesn't pass extra props to children. The search result item components have to get the info from Redux state.
Also there is no hook for when SearchKit updates location
.
Maybe SearchKit can be patched so it goes through FlowRouter
to update the location
. This would be ideal.
The current workaround is to read location
info whenever SearchKit query returns. It looks like the location
is updated in-between SearchKit sending a request and receiving the response. When the value of location
is read, save it into global Redux state, then read it in the search result item components.
location
updating, other than a customizable history
API. It looks like SearchKit is purely using the history
API to update the location
. Therefore providing a compliant history
API that receives the location
-changing requests and calls FlowRouter accordingly should do the trick.Trying to mock a history
interface for FlowRouter
.
The idea is to pass the search query (basically everything in the search string on Search Page) to other pages as a query parameter, then other pages can use this value to go back to the specific state of the search page.
This is limited to how much of the state is preserved in the url, but is a more generic solution since it works across page redirections.