Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Data: Include more details when shallow equality fails in 'useSelect' #67713

Merged
merged 3 commits into from
Dec 9, 2024
Merged

Data: Include more details when shallow equality fails in 'useSelect' #67713

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9f92c5e
Data: Include more details when shallow equality fails in 'useSelect'
Mamaduka Dec 8, 2024
39bc8c1
Simplify keys logic
Mamaduka Dec 9, 2024
b53a3a3
Update early return condition
Mamaduka Dec 9, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 20 additions & 4 deletions packages/data/src/components/use-select/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,25 @@ import useAsyncMode from '../async-mode-provider/use-async-mode';

const renderQueue = createQueue();

function warnOnUnstableReference( a, b ) {
if ( ! a || ! b ) {
return;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Object.keys should work equally well also for arrays. The only difference is that .keys() returns numbers, while Object.keys are strings.

The a.constructor check will crash when a is null or undefined, we should guard for that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Object.keys should work equally well also for arrays. The only difference is that .keys() returns numbers, while Object.keys are strings.

Yeah. I should have guessed that 😅

The a.constructor check will crash when a is null or undefined, we should guard for that.

I've borrowed the check for isShallowEqual, so it should be safe in this case.

Based on your suggestion, I think we can simplify logic to the example below. What do you think?

const keys =
	typeof a === 'object' && typeof b === 'object'
		? Object.keys( a ).filter( ( k ) => a[ k ] !== b[ k ] )
		: [];

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've borrowed the check for isShallowEqual, so it should be safe in this case.

But isShallowEqual does an if ( a && b ) check before it starts looking at a.constructor.

typeof a === 'object' && typeof b === 'object'

typeof null is also 'object' 🙀 It will all work only if you exit early when a or b is falsy.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should stop ignoring the "everything is an object" JS motto 😄

Pushed update in 39bc8c1.


const keys =
typeof a === 'object' && typeof b === 'object'
? Object.keys( a ).filter( ( k ) => a[ k ] !== b[ k ] )
: [];

// eslint-disable-next-line no-console
console.warn(
'The `useSelect` hook returns different values when called with the same state and parameters.\n' +
'This can lead to unnecessary re-renders and performance issues if not fixed.\n\n' +
'Non-equal value keys: %s\n\n',
keys.join( ', ' )
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The warning will be confusing when the b object has some field that the a object doesn't have. Then it will report an empty list of non-equal keys.

It can happen in practice when we write code like this:

useSelect( select => {
  if ( someCondition ) {
    return { loading: false };
  }
  return { loading: false, data: select( store ).getData() };
} );

To fix this, we could construct a set of all fields on both objects and then filter it:

const allKeys = Array.from( new Set( [ ...Object.keys( a ), ...Object.keys( b ) ] ) );
const keys = allKeys.filter( ( k ) => a[ k ] !== b[ k ] );

But this will fail again for objects like {} and { a: undefined } which are not shallow equal but keys will be [].

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The warning will be confusing when the b object has some field that the a object doesn't have. Then it will report an empty list of non-equal keys.

It means that the b run happened with different state or parameters (mostly params, based on your example). That shouldn't be the case for this warning, as it only makes sense with the same state/params.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh that's true, I've been overthinking it 🙂 Running the mapSelect callback twice with the same state shouldn't produce objects like this unless you're doing it on purpose.

}

/**
* @typedef {import('../../types').StoreDescriptor<C>} StoreDescriptor
* @template {import('../../types').AnyConfig} C
Expand Down Expand Up @@ -159,10 +178,7 @@ function Store( registry, suspense ) {
if ( ! didWarnUnstableReference ) {
const secondMapResult = mapSelect( select, registry );
if ( ! isShallowEqual( mapResult, secondMapResult ) ) {
// eslint-disable-next-line no-console
console.warn(
`The 'useSelect' hook returns different values when called with the same state and parameters. This can lead to unnecessary rerenders.`
);
warnOnUnstableReference( mapResult, secondMapResult );
didWarnUnstableReference = true;
}
}
Expand Down
Loading