Enhanced query filter blocks [rebased and updated]#39
Enhanced query filter blocks [rebased and updated]#39goldenapples wants to merge 3 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.
| '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
| <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.
| /> | ||
| { ( 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
| <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...?
2 participants
See #25 - this is the same branch, just cleaned up with phpcbf to follow the formatting standards of this project.