ContentPicker / ContentSearch - changing content type does not trigger a new search
Describe the bug
The ContentSearch component will run a new search when the search term changes. But if the search term stays the same while the content type changes, a new search is not run; instead the spinner shows indefinitely. Below is a minimal test case to show the issue.
Expected behavior: When the content type changes, the a new search query should run.
I'd be happy to help but probably not for a couple weeks, so no problem if someone else wants to pick it up.
Side note, I have looked over the ContentSearch component and feel that it needs some general cleanup beyond this bug (modernizing syntax, rearchitecting to eliminate the need for ESLint ignores, particularly with exhaustive dependencies), but that's probably a separate issue.
Steps to Reproduce
- Add the block code snippet to your WP theme
- Insert the block in the editor
- Enter a search term
- Change the post type
- See the infinite spinner
Screenshots, screen recording, code snippet
import { registerBlockType } from '@wordpress/blocks';
import { useState } from '@wordpress/element';
import { ContentPicker } from '@10up/block-components';
const Edit = () => {
const [posts, setPosts] = useState([]);
const [postType, setPostType] = useState('post');
return (
<>
<select onChange={(e) => setPostType(e.target.value)} value={postType}>
<option value="post">Post</option>
<option value="page">Page</option>
</select>
<ContentPicker
content={posts}
label="Search Posts"
onPickChange={setPosts}
contentTypes={[postType]}
/>
</>
);
};
// Register the test block type.
registerBlockType('jw/test', {
title: 'ContentPicker Test',
icon: 'admin-post',
category: 'widgets',
edit: Edit,
save: () => null,
});
Environment information
No response
WordPress information
WP 6.2
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
I would like to tackle this this Friday as it's relevant to a project I'm working on. But rather than scoping it to this one bug, I would like to focus on eliminating the need for this eslint-disable:
https://github.com/10up/block-components/blob/7f5e30a6c96db8fd4845f330dc54ce1c3def924b/components/content-search/index.js#L251
In my experience, this particular eslint-disable almost always leads to bugs and odd side effects such as the issue noted here and is a sign the component needs some rearchitecting. So I think the outcome of this issue should be to (1) eliminate that eslint-disable, (2) fix this bug, (3) have all ContentPicker and ContentSearch functionality otherwise unaffected.
cc @fabiankaegy
@johnwatkins0 Were you ever able to make progress on this issue? If not I can take a look at it :)
Working on it @fabiankaegy
This issue has been fixed in version 1.19.0