> blindly applying React.memo should be a huge win
That’s what the react compiler does, and it’s a good idea in that case because the compiler knows how to do it correctly, for _everything_. When humans try to do it, they will likely get it wrong (see the real world example in the article, this is the norm imo).
> Adding non-primitive props you get passed into your component to internal dependency arrays is rarely right, because this component has no control over the referential stability of those props.
Expecting referential transparency is a fine constraint. Inversely, the useRef technique might lead to its own weirdness where your UI is using some stale composite object that your event handler doesn't see anymore (and I prefer slow perf to chasing down correctness issues because you have a ref _and_ you have some accidental mutability somewhere in the stack _and_ you have stale UIs)
author here , sorry for the confusion. I did not mean to imply that leaving out the prop from useCallback is better - you _always_ have to adhere to the exhaustive-deps lint rule to avoid stale closures (I have a separate blog post on this topic).
What I meant is that the API design of B, where the hook only works as intended if the consumer A memoizes the input props, is not ideal because A has no way of knowing that they have to memoize it unless they look at the implementation or it’s clearly documented (which it rarely is). It’s not A’s problem because B could’ve used the latest ref pattern (or, in the future, useEffectEvent) to work without passing that burden onto its consumers.
so cacheTime was really confusing because it seemed like "this is the amount time we cache data for", but that's not what it is. So a rename had to happen. We had some discussion on the public roadmap (https://github.com/TanStack/query/discussions/4252) about what it's gonna be. I'm usually against abbreviations, simply because there's always someone who doesn't understand what it means. But all other suggestions like inactiveCacheTime also had room for interpretation. gc is an abbreviation that is known well enough (think git gc), and it's also not an option that you will customize on a daily basis (usually once, globally).
That’s what the react compiler does, and it’s a good idea in that case because the compiler knows how to do it correctly, for _everything_. When humans try to do it, they will likely get it wrong (see the real world example in the article, this is the norm imo).