block-components icon indicating copy to clipboard operation
block-components copied to clipboard

ContentPicker / ContentSearch - changing content type does not trigger a new search

Open johnwatkins0 opened this issue 2 years ago • 3 comments

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

  1. Add the block code snippet to your WP theme
  2. Insert the block in the editor
  3. Enter a search term
  4. Change the post type
  5. 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

johnwatkins0 avatar Mar 22 '23 23:03 johnwatkins0

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 avatar Mar 30 '23 14:03 johnwatkins0

@johnwatkins0 Were you ever able to make progress on this issue? If not I can take a look at it :)

fabiankaegy avatar May 24 '23 11:05 fabiankaegy

Working on it @fabiankaegy

johnwatkins0 avatar May 24 '23 14:05 johnwatkins0

This issue has been fixed in version 1.19.0

fabiankaegy avatar Jul 01 '24 19:07 fabiankaegy