wip: introduce parentIndexId #3690
Conversation
This would be useful for cases like https://github.com/algolia/react-instantsearch/discussions/3689#discussioncomment-4251317 where the cascade is working against your implementation. The reason this is WIP is because I think without having a bare root (without the workaround in App.tsx) you still need to prevent searches on the main index and that's still fairly "ugly". If InstantSearch would have an option to prevent mainIndex from searching (so actually having an array of root indices instead of a single one) it would be much more useful
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit bac47f7:
|
✅ Deploy Preview for react-instantsearch ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
| : item.label; | ||
| <Index | ||
| indexName="autocomplete_demo_products_query_suggestions" | ||
| parentIndexId="instant_search" |
There was a problem hiding this comment.
more ideally parentIndexId={null} would behave as another mainIndex, but not sure how that can be done. It could of course be implemented later as well
There was a problem hiding this comment.
I think we can resolve null to useInstantSearchContext().indexName.
There was a problem hiding this comment.
yep, null could be mainIndex, but it wouldn't really solve the issue here (needing to have a manual index at the root with different indexId), as that mainIndex would probably have widgets as well, negating the point of parentId a bit (I could almost only imagine use cases where you want no parameters to be inherited)
There was a problem hiding this comment.
I wonder how easier the mental model would be if we require an <Index> within <InstantSearch>.
Because we can't really portal an <Index> to an empty Helper in the current state. The root is shared among all <Index>.
(I see this problem a bit like Element and Fragment.)
There was a problem hiding this comment.
Yep, that's what I had in mind as well, possibly that could be detected when the InstantSearch instance doesn't receive an indexName prop, you render Index manually, and thus will be able to have adjacent root indices
This would be useful for cases like https://github.com/algolia/react-instantsearch/discussions/3689#discussioncomment-4251317 where the cascade is working against your implementation.
The reason this is WIP is because I think without having a bare root (without the workaround in App.tsx) you still need to prevent searches on the main index and that's still fairly "ugly". If InstantSearch would have an option to prevent mainIndex from searching (so actually having an array of root indices instead of a single one) it would be much more useful