daedalus28
commented
5 years ago 23 addressed the primary use case of this in the subquery type - however it is not a native part of the DSL and is just a type. The disadvantage of that approach is that it will be difficult to use dynamically changing subqueries from within the UI (at that point, we'd probably just use the client side approach).
To elaborate on that a little further - by relying on a search blob prop on subquery, making it interactive would be difficult since the inner search is just a blob and not a reactive tree controlled by the client. Even if we had a separate tree and just subscribed to the whole blob, not every action dispatched to the inner tree should actually traverse up the chain - only others reactors. If, for example, you just click "view more" on a facet, that wouldn't change the underlying search and so should not cause the outer search to trigger an update.
This ticket is to track the native implementation of join "in", which is like a
select in.Providers will need a way to specify how to get terms for a field, and the core will need to be able to short-circuit the tree traversals for
ins and use the new API to get the terms for group node with aninjoin.