React orchestrates Components and Hooks
React takes care of when your code runs for you so that your application has a great user experience. It is declarative: you tell React what to render in your component’s logic, and React will figure out how best to display it to your user.
Never call component functions directly
Components should only be used in JSX. Don’t call them as regular functions.
React must decide when your component function is called during rendering. In React, you do this using JSX.
function BlogPost() {
return <Layout><Article /></Layout>; // ✅ Only use components in JSX
}
function BlogPost() {
return <Layout>{Article()}</Layout> // ❌ Never call them directly
}
If a component contains hooks, it’s easy to violate the Rules of Hooks when components are called directly in a loop or conditionally.
Letting React orchestrate rendering also allows a number of benefits:
- Components become more than functions. React can augment them with features like local state through Hooks that are tied to the component’s identity in the tree.
- Component types participate in reconcilation. By letting React call your components, you also tell it more about the conceptual structure of your tree. For example, when you move from rendering
<Feed>
to the<Profile>
page, React won’t attempt to re-use them. - React can enhance your user experience. For example, it can let the browser do some work between component calls so that re-rendering a large component tree doesn’t block the main thread.
- A better debugging story. If components are first-class citizens that the library is aware of, we can build rich developer tools for introspection in development.
- More efficient reconcilation. React can decide exactly which components in the tree need re-rendering and skip over the ones that don’t. That makes your app faster and more snappy.
Never pass around hooks as regular values
Hooks should only be called inside of components. Never pass it around as a regular value.
Hooks allow you to augment a component with React features. They should always be called as a function, and never passed around as a regular value. This enables local reasoning, or the ability for developers to understand everything a component can do by looking at that component in isolation.
Passing around hooks as regular values also inhibits the compiler at performing optimizations. Breaking this rule will de-optimize your component.
Don’t dynamically mutate a hook
Hooks should be as “static” as possible. This means you shouldn’t dynamically mutate them. For example, this means you shouldn’t write higher order hooks:
function ChatInput() {
const useDataWithLogging = withLogging(useData); // ❌
const data = useDataWithLogging();
}
Hooks should be immutable and not be mutated. Instead of mutating a hook dynamically, create a static version of the hook with the desired functionality.
function ChatInput() {
const data = useDataWithLogging(); // ✅
}
function useDataWithLogging() {
// ... Create a new version of the Hook and inline the logic here
}
Don’t dynamically use hooks
Hooks should also not be dynamically used: for example, instead of doing dependency injection in a component by passing a hook as a value:
function ChatInput() {
return <Button useData={useDataWithLogging} /> // ❌
}
You should always inline the call of the hook into that component and handle any logic in there.
function ChatInput() {
return <Button />
}
function Button() {
const data = useDataWithLogging(); // ✅
}
function useDataWithLogging() {
// If there's any conditional logic to change the hook's behavior, it should be inlined into
// the hook
}
This way, <Button />
is much easier to understand and debug. When Hooks are used in dynamic ways, it increases the complexity of your app greatly and inhibits local reasoning, making your team less productive in the long term. It also makes it easier to accidentally break the Rules of Hooks that hooks should not be called conditionally. If you find yourself needing to mock components for tests, it’s better to mock the server instead to respond with canned data. If possible, it’s also usually more effective to test your app with end-to-end tests.