You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been using Slinky for quite sometime, all the while thinking that per the react.js docsuseCallback and useMemo 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 or useMemo that takes other types, e.g.: useCallback[String](...)
React.withHooks(()=>{constinputState=React.useState('Hello, world!');constonButtonClick=React.useCallback((props)=>((e)=>{const[input]=inputState;alert(e);}),(props)=>[inputState[0]]);return(props)=>{const[input,setInput]=inputState;return(<><inputvalue={input}onChange={(e)=>setInput(e.currentTarget.value)}/><buttononClick={onButtonClick('data I need to send not controlled in state')}>Alert</button></>);};})
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:
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:
The text was updated successfully, but these errors were encountered: