Conditional useSelect not working as expected

[davilera]

Description

useSelect doesn't re-render a component after the store is updated if useSelect's callback uses the select argument conditionally. In other words...

This hook doesn't work:

useValue = ( condition ) => useSelect( ( select ) =>
  !! condition ? select( STORE ).getValue() : ''
);

but this one does:

useValue = ( condition ) => useSelect( ( select ) => {
  const { getValue } = select( STORE );
  return !! condition ? getValue() : '';
} );

Step-by-step reproduction instructions

1. Open Gutenberg
2. Open your browser's JS console
3. Register a simple store to keep track of a single string:

STORE_NAME = 'david/test';
wp.data.register(
  wp.data.createReduxStore( STORE_NAME, {
    reducer: ( state = '', action ) =>
      action.type === 'SET_VALUE' ? action.value : state,
    actions: {
      setValue: ( value ) => ( { type: 'SET_VALUE', value } ),
    },
    selectors: {
      getValue: ( state ) => state,
    },
  } )
);

4. Create a simple component to test the useSelect logic:

Main = () => {
  const { useEffect, useState, createElement: el } = wp.element;
  const { useSelect, useDispatch } = wp.data;

  const [ text, setText ] = useState( '' );
  const link = ( ` ${ text } `.match( / https?:\/\/[^ ]+ / ) || [ '' ] )[0].trim();

  // Conditional read from store
  const value = useSelect( ( select ) =>
    !! link ? select( STORE_NAME ).getValue() : ''
  );

  // Write to store
  const { setValue } = useDispatch( STORE_NAME );
  useEffect( () => {
    setValue( link );
  }, [ link ] );
  
  const { TextControl } = wp.components;
  return el( 'div', {}, [
    el( TextControl, { key: 'text-control', value: text, onChange: setText } ),
    el( 'pre', { key: 'pre' }, JSON.stringify( value ) ),
  ] );
}

(This component lets you write some text. It extracts the first link and saves it in the store with a useEffect).

6. Render the component:

document.body.innerHTML = '<div id="root"></div>';
wp.element.render( wp.element.createElement( Main ), document.getElementById( 'root' ) );

7. Copy and paste the following text in the TextControl: Hello, World. https://example.com

Expected behavior: You should see "https://example.com" in the pre tag
Actual behavior: You see the empty string "", even though wp.data.select( STORE_NAME ).getValue() returns the proper value https://example.com.

Screenshots, screen recording, code snippet

No response

Environment info

• WordPress 6.1.1 without Gutenberg

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[TimothyBJacobs]

The useSelect hook accepts a dependencies array as it's second parameter like other React hooks. Your link value should be passed to this dependency array, which I think should fix your issue.

const value = useSelect( ( select ) =>
    !! link ? select( STORE_NAME ).getValue() : '',
    [ link ]
  );

[davilera]

Thanks for the tip, @TimothyBJacobs. It looks like, indeed, the dependency array fixes the issue.

I was just surprised that this hook doesn't work:

useValue = ( condition ) => useSelect( ( select ) =>
  !! condition ? select( STORE ).getValue() : ''
);

but this one does:

useValue = ( condition ) => useSelect( ( select ) => {
  const { getValue } = select( STORE );
  return !! condition ? getValue() : '';
} );

as if the mere act of calling the select once did some magic behind the scenes.

If that were the case, I think it'd be a good idea if we could explicitly mention this in the documentation. What do you think?

[youknowriad]

Related to the discussion we had in the useSelect refactoring PR cc @jsnajdr @kevin940726

[youknowriad]

I agree that we should either fix this as a bug or mention in the documentation that conditional selects are not supported.

[jsnajdr]

Let's fix this as a bug -- it shouldn't be terribly hard or expensive to compare the list of selected stores after each call. Especially with the new useSyncExternalStore implementation.

[jsnajdr]

Proposing a fix in #47243.