New hook: useSafeTimeout

[ellatrix]

Description

Moves the logic within withSafeTimeout to the new hook useSafeTimeout.

How has this been tested?

Screenshots

Types of changes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR. .

[ellatrix]

Should we use useCallback for these?

[youknowriad]

To be fair, I'm not sure whether we really need this hook. I feel this is just a Higher-order that was needed because of how class components work. I feel with hooks, we don't really need it.

[ellatrix]

@youknowriad Could you elaborate? Why won't we need it?

[youknowriad]

I feel when you use timeouts with hooks, you'll always do something like that;

useEffect(() =>  {
  const tid = setTimeout(dosomething);
  return () => clearTimeout(tid);
});

The timeout and its clearance are located in the same code, the chance to forget about this and the added code here is very small while in the case of a class Component or components without hooks, it's quite complex to achieve: you need refactor to a class component and use separate methods to trigger and clear the timeouts. All these are fixed with hooks.

[ellatrix]

Ah, you're right. I was thinking of a use case in RichText where setTimeout wouldn't be in useEffect, but this seems very rare.

[aduth]

Ah, you're right. I was thinking of a use case in RichText where setTimeout wouldn't be in useEffect, but this seems very rare.

There's now another example of this (timers in event handler) at #19881, though I'd agree that it's still not yet (to me) at a point to need a higher-level solution, and if anything its absence could serve as a deterrent to an anti-pattern.