Closed evbo closed 5 years ago
In the case of useMemo
, Slinky doesn't actually need a new API since A => T
can just be the type that the existing T
is inferred to be. I'll take a look at useCallback
, that's not something that Slinky handles right now.
I've been using Slinky for quite sometime, all the while thinking that per the react.js docs
useCallback
anduseMemo
should strictly take() => Unit
and() => T
as their first argument, respectively.But towards the bottom of this issue is a valid use-case for when a variable can't easily or conveniently be controlled in state, but must be referenced in the callback that you also might want memoized to avoid re-rendering the child you're passing it to.
Sure enough, if you play around with this code pen, you can write a valid
useCallback
oruseMemo
that takes other types, e.g.:useCallback[String](...)
Can Slinky hooks support the following instead? In these cases, the extra type is for an argument that isn't controlled in any state that would otherwise be watched as a dependency:
and would get used like:
Note that there is a work around, albeit forcing the
reducer
design pattern, which isn't always preferred by matter of coding convention:So instead of trying to implement:
You can just do the following for now: