Components with query loops attached to the root element of a component work fine and the query loop can be filtered and selected from outside e.g. use the {query_results_summary} or target the loop with a filter element.
Problem
However, any query loop added to a non-root element of a component, can not be addressed from outside. Also, custom PHP filters targeting the query loop via loopable Element ID do not work.
This problem is well known by the Bricks team, and fixing it would solve a huge shortcoming of Bricks components and many complaints.
Example
I built an event listing that automatically groups events of a day. I would love to use a query loop element and a code element to create the grouping, but that is no possible. Therefore, I used a workaround with JavaScript to dynamically create the structure at rendering time.
With the Bricks structure tree being forced to something like:
The query loop is then no longer targetable via query_vars filter targeting the loop element ID.
So a component that encapsulates the list and is filterable is not possible. This contradicts “component support” and is just one of 100 cases, where this component restriction hits you.
Solution
For a solid component integration, components need to behave like normal elements, except that the element structure is defined in one place. Any query loop used in Bricks needs to be targetable from outside.
Alternative
In this scenario, a query loop element would have also helped, as the code element would be obsolete.