4 ms·
Yes, but then you have to do as the author says: wrap every single function in a use callback and declare it dependencies. Otherwise it's unsafe to use for othe
by matsemann 1y ago
Yes, but then you have to do as the author says: wrap every single function in a use callback and declare it dependencies. Otherwise it's unsafe to use for others. Which to me is a broken design. And y in my case may not be my function, either from a library or somewhere else in the application I don't want to modify just because my usage needs it. It should be a compiler thing, not up to the devs, the abstraction feels off.
- p1necone 1y agoI think you've got this backwards. If you write a React component that internally uses some 3rd party component/hook, and on every render of your component you pass something as a prop to that 3rd party component that's different from the previous render you should expect that 3rd party component/hook to also rerender/rerun. This isn't really surprising, nor is it even a problem in most cases. If you're the one writing that reusable thing, you don't need to do anything special or write the kind of defensive code you're talking about. It's up to the original source of those props to make sure they're not creating new objects every render if they're in a context where that even matters
- matsemann 1y agoI don't mean I'm passing new stuff to the 3rd party hook, but that it returns a function that's usecallbacked, and hence I cannot myself use it as a dependency in a useEffect without it triggering every render. So yeah, if you expose a function in a piece of reusable code, you must useCallback around everything and be very defensive, or you mess up for those integrating with you.