Note to self: Add a note about this special workaround.

It seems we're "forced" to do similar filter/map/reduce hacks more often. Maybe there's a better alternative. cc @jsnajdr, @talldan, @tyxla

Examples:

• gutenberg/packages/patterns/src/components/overrides-panel.js

  Lines 27 to 34 in 802a127

  	const clientIdsWithOverrides = useMemo(
  	() =>
  	allClientIds.filter( ( clientId ) => {
  	const block = getBlock( clientId );
  	return isOverridableBlock( block );
  	} ),
  	[ allClientIds, getBlock ]
  	);

• gutenberg/packages/block-editor/src/components/block-inspector/index.js

  Lines 134 to 157 in 802a127

  	// Separate useSelect for contentClientIds with proper dependencies
  	const contentClientIds = useSelect(
  	( select ) => {
  	if ( ! isSectionBlock || ! selectedBlockClientId ) {
  	return [];
  	}
  	const {
  	getClientIdsOfDescendants,
  	getBlockName,
  	getBlockEditingMode,
  	} = unlock( select( blockEditorStore ) );
  	const descendants = getClientIdsOfDescendants(
  	selectedBlockClientId
  	);
  	return descendants.filter(
  	( current ) =>
  	getBlockName( current ) !== 'core/list-item' &&
  	getBlockEditingMode( current ) === 'contentOnly'
  	);
  	},
  	[ isSectionBlock, selectedBlockClientId ]
  	);

What exactly is the "workaround" and "hack"? In all three code examples we select list of IDs with useSelect and getClientIdsWithDescendants and then transform the array somehow.

The transformation should always be outside the useSelect, inside useMemo, because it creates a new array even for identical input. Only the OverridesPanel example does it right. The other two will trigger a useSelect warning: "returns different values".

Hopefully React Compiler will help us automate this memoizing in the future.

The useSelect+useMemo pattern still has the disadvantage that there will be unneeded rerenders: useSelect result changes, but the useMemo result doesn't. In a truly ideal situation, the transformation would be wrapped in a memoized function:

const transform = memo( ( input ) => input.filter( ... ) );
const interestingIds = useSelect( ( select ) => transform( getClientIds() ) );

Here you get a rerender only when interestingIds really change.

What exactly is the "workaround" and "hack"?

It's a workaround because the returned object or array will pass a shallow equality check. They'll have the following shapes:

// Example object.
{ 'client1': 1, 'client2': 2, ... }

// Example array.
[ 'client1', 'client2', ... ]

The other two will trigger a useSelect warning: "returns different values".

I'm not able to trigger these warnings for the mentioned components.

Oh I see, there is the trick with returning the array itself instead of { result: theArray }. Then there's the shallow equality check. I agree it's a workaround.

For me, the ideal situation is that we have ergonomic tooling for doing the filter/reduce 1) inside useSelect 2) memoized. Something like:

const getCommentIds = useMemoizedCallback( ( ids ) => ids.reduce( ... ), [] );
const { blocksWithComments } = useSelect( ( select ) => {
  const blocks = select( be ).getClientIdsWithDescendants();
  return { blockWithComments: getCommentIds( blocks ) };
}, [] );

Here the useMemoizedCallback has some cache inside that resets when the dependencies change.

I think this could be a nice library addition that would have a lot of potential usage across wp-data-using codebases.