DISCLAIMER: This is not a tutorial, this is part of the story of building ACF Engine. Hopefully, our eventual tutorials on this topic will be a lot more helpful to developers in the midst of using ACF Engine.
Today (November 19, 2020) the work on Filters and associated Queries continues. These are both pro features in ACF Engine. The queries currently act as a wrapper for get_posts(), enabling a UX for building queries including meta queries. The concept of Filters is to work with one or (possibly) more Queries, and enable a front-end filtering of the post data. Simple enough to do in code, but challenging to “present as a UX”.
At one point I considered making Filters defined along with a given Query. That would likely have made things simpler to build, but I also feel some flexibility might have been lost. Although there is a strong relationship between a Query and a Filter, they are not the same. A Filter provides context to and changes the result of a Query. It isn’t actually part of a query, the way I see it. It’s more of a UX element that sends a request to change a query, and triggers reloading of data.
The question is where does the Filter end, and the Query begin, or how do we define that relationship in the UX? And how does the Filter, or the Query for that matter, know what to do with the new data in terms of rendering?
Here is what we’re working towards as a complete system with 3 components:
- Query (post query only currently, later other forms of object data queries). For example this could be a “property” post type query, the goal to fetch 50 properties.
- Filter (post meta filter). For example this a “property_type” meta field to adjust the property filter.
- Query powered rendering block. This is a block type (such as our existing Single Page App block type) that is powered by a query.
The data flow then with these 3 components would be that:
- When the user changes the filter, the filter sends a request to the rendering block to do a refresh of data.
- The rendering block applies the filter to the query, then runs the query and refreshes it’s data display.
Worth noting also that “Filters” are ACF Engine objects, just like Post Types, Taxonomies etc. That means they are stored as JSON data and can be migrated or bundled into ACFG Components. To display a filter, we’re going to provide a number of Filter block types where you specify the filter key, and then it is rendered.