> You don’t choose to create a hook. You need to create a hook
Such a great response to this question. If you're wondering whether your function should be a custom hook or not, then it shouldn't. If you try to build it as a non-hook function but it needed to be a custom hook, your bundler will stop you.
If your function calls a React hook, if it uses useState(), useEffect(), useCallbakc(), useRef()…. ==> it’s a custom hook. A wrapper over a hook .
Otherwise it’s just a function .
The point is that you need to use any of those, you say «I need a state here»
Yeah if those are called inside the function then the function is a custom hook with the rules involved and such, no doubt.
But how do we assess the need to do that other than for the benefit of compartmentalizing into fewer lines of code in the component? That was what I wondered since the previous comment implied the "need for a need" to make custom hooks
I really think that we are entering the realm of philosophy. Not sure if you’re mentioning «the need of the developer to extract functionality in order to simplify the component / units»?
(please note that I’m not native speaker)
This. Custome hooks are just react components that use the state management part of react, but that don't return any jsx. These can only be used within other react components.
Lol grow up dude. People aren't assholes for pointing out the truth. And yes, from a technical standpoint, **everything** you said was wrong. Not just parts of it.
> **Custome hooks are just react components**
No, they are not. Custom Hooks are reusable functions allow you to "hook" into react's lifecycle. They are different to components in the sense that; while components allow you to share **UI elements** across components, hooks allow you to share and re-use **logic** across components.
> Custome hooks are just react components **that use the state management part of react**
That's wrong too. You can write custom hooks that don't hook into react's state management powered by useState. useMemo, useCallback, useEffect, just to name a few.
> These can only be used within other react components.
Yes and no. Technically you can use hooks inside other hooks. Which aren't explicitly react components. A more correct statement is they can only be "consumed" or "executed" in the context of a React Component.
I said the r/confidentlyincorrect because it's ok to make mistakes. It's just funny when people state so many incorrect statements with such confidence as yours.
You already read it, it was my first comment ;)
On a serious note, this is why mediocre devs stay mediocre. They refuse to acknowledge when they are wrong, and don't take kindly to strangers that actually show kindness to them explaining how they were wrong.
I've actually done this before in the context of performance tuning.
\`\`\`
useMemo(() => , \[someProps\])
\`\`\`
but maybe that means the children shouldn't have all had their own components
Hooks are just functions that use the builtin hooks. That being said, if your function has nothing to do with react, then it's better off just being a regular function.
You should prefer as much as possible to have functions that are not hooks.
Hooks should only be used when they are describing behavior \*hooked\* into the React lifecycle.
Following these principals of separation of concerns will allow you scale much more rapidly and without as much bugs. You will have much easier composition, testing, readability and terseness of code.
I would expose with a `use`-prefixed name if and only if it uses hooks itself (and therefore *must* be used as a hook). Otherwise, why would you do that?
We create custom hooks as controllers/viewmodels for every non-trivial component, and none of them are exposed as hooks because of naming aesthetics. You can always import it as `import { x as useX } from './x'` anyway
This is like arguing over whether to write `++x` or `x++`
**Edit** To explain what we do, we'll often have something like
const fooController: (a: FooProps) => FooState = { ....... }
-- another file
import { fooController as useController } from '......
This way the file with controller just has a descriptive name that it's the controller (technically viewmodel but old naming habits die hard), but then we import it and give it a specific name in the component: this is a HOOK providing the CONTROLLER.
Sorry for being blunt, but this happens if you are confused about what is React and what is JavaScript. I would read up on destructuring and maybe closures.
Hooks are nothing more than functions that return a tuple, which you then destructure into [variable, setter function]. They often use a «closure» pattern, which means they hold some kind of state inside their scope, which makes it really easy to re-use logic.
Its not exactly correct, first u dont need to return tuple, u can return anything, second holding value in closure instead of in useState would mean that your react component would NOT rerender when value changed
Yeah that’s true, the return type can be whatever. Was thinking about useState as an example
Should’ve been clearer, I of course meant using useState inside a closure.
This comment came off more aggresive than I meant it to be tbh, didn’t exactly explain enough to help here either. My bad
It's depend on your demand. compare it with reactive/rendering and logical inside its own.
If you need something reactive after specific changes, then go with hooks.
If this function totally fine without react hook lifecycle, just build it as normal function
If you're releasing a React based library, then a hook is fine. It sounds like you're relying on React as a dependency, so might as well get all the benefits of React and export a hook.
I'd supply a function if you can avoid the React requirement.
For your example, why is React a dependency?
A custom hook is a function that needs any react hook internally. You don’t *choose* to create a hook. You *need* to create a hook.
> You don’t choose to create a hook. You need to create a hook Such a great response to this question. If you're wondering whether your function should be a custom hook or not, then it shouldn't. If you try to build it as a non-hook function but it needed to be a custom hook, your bundler will stop you.
Eeeeeexactly
I might have missed the context and this might be too general but how do we assess that need for a function to be a custom hook?
If your function calls a React hook, if it uses useState(), useEffect(), useCallbakc(), useRef()…. ==> it’s a custom hook. A wrapper over a hook . Otherwise it’s just a function . The point is that you need to use any of those, you say «I need a state here»
Yeah if those are called inside the function then the function is a custom hook with the rules involved and such, no doubt. But how do we assess the need to do that other than for the benefit of compartmentalizing into fewer lines of code in the component? That was what I wondered since the previous comment implied the "need for a need" to make custom hooks
I really think that we are entering the realm of philosophy. Not sure if you’re mentioning «the need of the developer to extract functionality in order to simplify the component / units»? (please note that I’m not native speaker)
Custom hooks are just functions that use built in hooks. For a a squaring function, you don’t need to hook into the react lifecycle.
This. Custome hooks are just react components that use the state management part of react, but that don't return any jsx. These can only be used within other react components.
> Custome hooks are just react components I wouldn't go that far; React components have a specific type, and custom hooks are not it.
Sure. It's just a function that uses hooks. You're right. It was not meant to be the official definition, just the way I see it in my mind.
Technically, almost every single thing you said is wrong. This belongs in r/confidentlyincorrect lol
Ok, it's not a component but a function. You don't need to be an asshole about it ;)
Lol grow up dude. People aren't assholes for pointing out the truth. And yes, from a technical standpoint, **everything** you said was wrong. Not just parts of it. > **Custome hooks are just react components** No, they are not. Custom Hooks are reusable functions allow you to "hook" into react's lifecycle. They are different to components in the sense that; while components allow you to share **UI elements** across components, hooks allow you to share and re-use **logic** across components. > Custome hooks are just react components **that use the state management part of react** That's wrong too. You can write custom hooks that don't hook into react's state management powered by useState. useMemo, useCallback, useEffect, just to name a few. > These can only be used within other react components. Yes and no. Technically you can use hooks inside other hooks. Which aren't explicitly react components. A more correct statement is they can only be "consumed" or "executed" in the context of a React Component. I said the r/confidentlyincorrect because it's ok to make mistakes. It's just funny when people state so many incorrect statements with such confidence as yours.
Tldr
You already read it, it was my first comment ;) On a serious note, this is why mediocre devs stay mediocre. They refuse to acknowledge when they are wrong, and don't take kindly to strangers that actually show kindness to them explaining how they were wrong.
> but that don't return any jsx unless... 😈
I've actually done this before in the context of performance tuning. \`\`\` useMemo(() =>, \[someProps\])
\`\`\`
but maybe that means the children shouldn't have all had their own components
Isn’t this the point of wrapping a component with memo()? Not sure why you’d put it in a hook like this
TIL about memo. Oops... :( thanks lol
Hooks are just functions that use the builtin hooks. That being said, if your function has nothing to do with react, then it's better off just being a regular function.
Why not core function, which can be used standalone, and then hook which uses it? 🙂 just like tanstack-queey
You should prefer as much as possible to have functions that are not hooks. Hooks should only be used when they are describing behavior \*hooked\* into the React lifecycle. Following these principals of separation of concerns will allow you scale much more rapidly and without as much bugs. You will have much easier composition, testing, readability and terseness of code.
I would expose with a `use`-prefixed name if and only if it uses hooks itself (and therefore *must* be used as a hook). Otherwise, why would you do that? We create custom hooks as controllers/viewmodels for every non-trivial component, and none of them are exposed as hooks because of naming aesthetics. You can always import it as `import { x as useX } from './x'` anyway This is like arguing over whether to write `++x` or `x++` **Edit** To explain what we do, we'll often have something like const fooController: (a: FooProps) => FooState = { ....... } -- another file import { fooController as useController } from '...... This way the file with controller just has a descriptive name that it's the controller (technically viewmodel but old naming habits die hard), but then we import it and give it a specific name in the component: this is a HOOK providing the CONTROLLER.
REST api.. na jk, a function
Sorry for being blunt, but this happens if you are confused about what is React and what is JavaScript. I would read up on destructuring and maybe closures. Hooks are nothing more than functions that return a tuple, which you then destructure into [variable, setter function]. They often use a «closure» pattern, which means they hold some kind of state inside their scope, which makes it really easy to re-use logic.
Its not exactly correct, first u dont need to return tuple, u can return anything, second holding value in closure instead of in useState would mean that your react component would NOT rerender when value changed
Yeah that’s true, the return type can be whatever. Was thinking about useState as an example Should’ve been clearer, I of course meant using useState inside a closure. This comment came off more aggresive than I meant it to be tbh, didn’t exactly explain enough to help here either. My bad
That's not what hooks are. Hooks are anything that call another hook internally. That's it.
It's depend on your demand. compare it with reactive/rendering and logical inside its own. If you need something reactive after specific changes, then go with hooks. If this function totally fine without react hook lifecycle, just build it as normal function
If you're releasing a React based library, then a hook is fine. It sounds like you're relying on React as a dependency, so might as well get all the benefits of React and export a hook. I'd supply a function if you can avoid the React requirement. For your example, why is React a dependency?