Enhanced query filter blocks [rebased and updated]#39
Enhanced query filter blocks [rebased and updated]#39goldenapples wants to merge 5 commits intomainfrom
Conversation
goldenapples
force-pushed
the
enhanced-query-filter-blocks-updated
branch
3 times, most recently
from
167000c to
2ee049c
Compare
… direction - Updated package.json to include @wordpress/env as a dev dependency. - Added new attributes `displayType` and `layoutDirection` to block.json for post-type and taxonomy blocks. - Modified the Edit component for post-type and taxonomy blocks to include SelectControl for display type and ToggleGroupControl for layout direction. - Implemented conditional rendering for select, radio, and checkbox inputs based on the selected display type. - Updated render.php files for post-type and taxonomy blocks to handle new display type and layout direction attributes. - Added styles for radio and checkbox groups in style-index.css to support vertical and horizontal layouts. - refactor: Remove shared styles registration and update label classes in taxonomy render Build changes to render files
goldenapples
force-pushed
the
enhanced-query-filter-blocks-updated
branch
from
2ee049c to
f642d79
Compare
kadamwhite
left a comment
kadamwhite
left a comment
There was a problem hiding this comment.
The patch looks sensible and I didn't see any blocking issues while reviewing, 
!
Only called out a few areas where we could conceivably clean up apparently-duplicated UI and options code, and asked about whether the boolean tax query logic should be more explicitly spelled out in a comment.
Note: have not tested locally.
inc/namespace.php
Outdated
| 'taxonomy' => $key, | ||
| 'terms' => $values, | ||
| 'field' => 'slug', | ||
| 'operator' => 'IN', // This creates OR logic |
There was a problem hiding this comment.
Might be good to expand this comment to explicitly clarify the relationship between 'operator' and $tax_query['relation'] = 'AND', above — I've seen this lead to confusion in other projects
There was a problem hiding this comment.
Update in b31e558. I'm also not sure if we should add an option for this logic on the filter settings. This IN logic seems like the most common use case to me, but I have seen faceting controls where selecting an additional term is expected to drill down into results rather than widening the search.
There was a problem hiding this comment.
My default approach to filtering (and what I think most users expect / understand intuitively) is OR between multiple Terms in a Taxonomy and AND between multiple Taxonomies. Which is what is being done now. But more code comments can't hurt. I think if there's a setting it should be user-facing which may a bigger discussion for the dev team? Thanks for working on the PR though. Can't want to have multiple form options merged into the main branch!
There was a problem hiding this comment.
Agreed with @goldenapples, IN logic seems like the most common use case to me as well. No need for an extra setting right now IMO.
| <SelectControl | ||
| label={ __( 'Display Type', 'query-filter' ) } | ||
| value={ displayType } | ||
| options={ [ |
There was a problem hiding this comment.
Nitpick, since these options are static (not dependent on other state) I'd recommend to hoist them up to a const DISPLAY_TYPE_OPTIONS or some such in the parent file scope outside of this component. Not blocking, strictly a preference thing; this doesn't get called in a loop enough that the recreated object reference would be a problem.
There was a problem hiding this comment.
I'd also like to see something of this nature, but I'd like to see that done as part of a bigger refactoring of display types. Ultimately each of these display types contains a lot of reusable logic that could be abstracted out, but I don't want to do a naive refactoring of a codebase I'm not fully familiar with and potentially make it harder to add new filter types in the future.
| /> | ||
| { ( displayType === 'radio' || | ||
| displayType === 'checkbox' ) && ( | ||
| <ToggleGroupControl |
There was a problem hiding this comment.
Does this mean that direction is not relevant with displayType === 'select' -- and if so, should the onChange for the displayType reset this to vertical if "select" is chosen? We don't use the layout option in select mode, today, but it doesn't read like we'd otherwise "reset" to the default vertical value if we switch off of the radio/checkbox options that allow for horizontal layout
There was a problem hiding this comment.
That makes sense to me. Is something like 862cfa7 what you have in mind?
| <SelectControl | ||
| label={ __( 'Display Type', 'query-filter' ) } | ||
| value={ displayType } | ||
| options={ [ |
There was a problem hiding this comment.
Realized these options are repeated, inclusive of their selection UI; worth extracting these components and sharing them between the taxonomy and post type blocks...?
There was a problem hiding this comment.
I definitely think so - especially as we're considering adding other filters like Author (#23). But I think that refactor can be done in a separate PR.
There was a problem hiding this comment.
There is an inconsistency in the apiVersion across the blocks, perhaps it would be a good idea to standardise this in this PR as well and set it to v3?
4 participants
See #25 - this is the same branch, just cleaned up with phpcbf to follow the formatting standards of this project.