Do React hooks really have to start with "use"?

Question

Lets' create a very simple hook useDouble that returns the double of a number:

export default function useDouble(nb) {
  return nb * 2;
}

The documentation (https://reactjs.org/docs/hooks-custom.html#extracting-a-custom-hook) reads:

A custom Hook is a JavaScript function whose name starts with ”use” and that may call other Hooks

But if I change useDouble to double, it still works. I even tried to call other hooks from the double hook, and it still works.

Demo: https://codesandbox.io/s/laughing-gareth-usb8g?file=/src/components/WithUseDouble.js

So my question is: is naming hooks useXxxxx just a convention, or can it really break something somehow? And if it can, could you show an example?

Thanks

Answer 1

React hook definition according to React docs:

A custom Hook is a JavaScript function whose name starts with ”use” and that may call other Hooks.

A perfect definition of a custom hook would be (notice the removal of "use" prefix and "may"):

A custom Hook is a JavaScript function that calls other Hooks.

So we could distinguish between helper functions and custom hooks.

But, we can't tell if certain functions are actually using hooks (we do know in runtime). Thats why we use static code analyzing tools (like eslint) where we analyze text (lexical) and not meaning (semantics).

This convention guarantees that you can always look at a component and know where its state, Effects, and other React features might “hide”. (Reusing Logic with Custom Hooks)

Should all functions called during rendering start with the use prefix? No. Functions that don’t call Hooks don’t need to be Hooks. (Reusing Logic with Custom Hooks)

... this convention is very important. Without it, we wouldn’t be able to automatically check for violations of Rules of Hooks because we couldn’t tell if a certain function contains calls to Hooks inside of it. (Legacy docs)

Hence:

// #1 a function
// CAN'T BREAK ANYTHING
function double(nb) {
  return nb * 2;
}

// #2 Still a function, does not use hooks
// CAN'T BREAK ANYTHING
function useDouble(nb) {
  return nb * 2;
}

// #3 a custom hook because hooks are used 
// CAN BREAK, RULES OF HOOKS
function useDouble(nb) {
  const [state, setState] = useState(nb);
  const doubleState = (n) => setState(n*2);
  return [state,doubleState];
}

---

Is naming hooks useXxxxx just a convention.

Yes, to help static analyzer to warn for errors.

Can it really break something somehow?

Example #2 can't break your application since it just a "helper function" that not violating Rules of Hooks, although there will be a warning.

Could you show an example?

// #2 from above
function useDouble(nb) { return nb * 2; }

// <WithUseDouble/>
function WithUseDouble() {
  // A warning violating Rules of Hooks 
  // but useDouble is actually a "helper function" with "wrong" naming
  // WON'T break anything
  if (true) {
    return <h1>8 times 2 equals {useDouble(8)} (with useDouble hook)</h1>
  }
  
  return null;
}

Answer 2

Do I have to name my custom Hooks starting with “use”? Please do. This convention is very important. Without it, we wouldn’t be able to automatically check for violations of rules of Hooks because we couldn’t tell if a certain function contains calls to Hooks inside of it

From reactjs/docs.

And in large components that use several functions, the "use" prefix also helps in easily identifying if a function is a custom hook.

Answer 3

Imagine that your project js code will be compressed and confused when it is released, and all your methods starting with use will become a, b, c, etc.

Therefore, letting developers start with use can only be a unified specification. The purpose is to facilitate eslint to recognize that this is a custom hooks, so that you can warn you when you violate the rules of using hooks and greatly reduce the occurrence of bugs.

For example, if you put the hooks function in the conditional branch, if it happens that this conditional judgment remains unchanged, there will be no error. In this way, there is a hidden danger in the code.