❌ When not to create a hook!

Hooks took the React application development by storm.

Before hooks, Class components were the only way to tap into the lifecycle of a component. But with the introduction of hooks, everything changed.

Hooks are how most lifecycle development happens in a general React application.

But it would be best if you did not put everything in hooks.

First, a few prominent points for when to create a hook.

Yay Reasons

• Separation of concern
• Reusability
• Encapsulation
• Abstraction

Nay Reasons

• Hiding a few lines with hooks
• Hooks for single-use functions
• Beautifying code with hooks
• Hooks to import or represent the static data

Let's go deeper into the reasons for creating a hook.

👍 Separation of Concern

If you want to keep all the moving parts related to each other, using hooks is an excellent way to go.

In the conventional model, the API communication layer should handle only API-related concerns, and the Data layer should be responsible for how the data should be transferred and transformed. Hence, keeping these two layers separate would help manage the application better.

Similarly, what needs to be done to access API is a separate concern and should be part of one hook, and what we need to do with the API, i.e., data sending, receiving, transforming, etc, via API, should be another hook.

👍 Reusability

Keeping the code clean is an excellent way to keep it maintainable. And one of the aspects that improve code clarity is reusability. And if you use certain functionality repeatedly in any application, making it a reusable block-like function or class makes sense.

And hooks are an excellent way to make reusable code in a React application. Logics related to local storage access, Navigation state, router state, etc., are good examples. Some are already available as part of libraries, and some you might want to write yourself.

👍 Encapsulation

Keeping all the related moving parts of an application together is the best way to ensure less confusion and bugs.

And hence encapsulating, or keeping all the related parts together, is a good candidate for hook creation.

For example, we have multilayered navigation and allow some custom items from the customer. In such cases, everything related to the state of the navigation menu, API handling for custom items, etc., can be encapsulated in one hook to provide seamless one-point access.

👍 Abstraction

We often need to handle application communication with third-party tools like APIs, browser extensions, etc. And in such cases, we are more unfortunate than lucky to find the communication interface filling out data format.

In such cases, we must have some abstraction for those tools to normalize the data before reading or writing.

Hooks are best for that. And you might have come across similar hooks which abstract the Browser History API via Hooks.

You can have similar cases of your hook for abstracting the communication with LocalStorage or WebSocket.

Now let's deep dive into the unnecessary reasons for the hooks.

👎 Hiding a few lines with hooks

I understand the components can grow humongous, and the urge to break them down is very itching. But hiding a few lines from a large component just by creating a hook can be a hurdle in maintainability.

Why? Because it directs the developers against the principles of Encapsulation and Abstraction. This main component is not encapsulated and is broken down into several files. This also causes code reading fatigue when overutilized.

👎 Hooks for single-use functions

Single-use functions are somewhat an extension of "Hiding few lines."

Indeed, if we can create a function to hide a few lines, let's do it. But now, these functions need access to existing hooks like routes or translations. We can transform it into a hook.

But, in the end, this hook will not be needed anywhere else. And all it did was hide a function that only hid a few lines of single-use code.

👎 Beautifying code with hooks

We all want our code to be clean, But if we misinterpret the clean code with visually appealing code, we might fall into this pitfall reason of creating a react hook.

Beautification can include the situations like the conditional rendering of the part of a large component, translating/transforming the elements of an object to different keys, etc.

It is good to beautify the code so it is pleasant to read and navigate. But it should be part of the structure, not an explicit effort. Any explicit effort to beautify code with the help of a hook will seem rougher while trying to make sense of it.

👎 Hooks to import or represent the static data

Static data is usually part of an application. And its inclusion is the application can be very straightforward or complicated, depending upon the situation.

And if it is already complicated and we also want to do some transformations on this static data, we might turn to hooks to simplify and encapsulate the whole process.

But the static data is just that, static data. We can transform it beforehand and not need the hook to load and transform it in the runtime.

And if you introduce such practice once, even if it is a one-time thing, other parts of the application or developers take inspiration. In those times, avoiding it is better than facing an ill-formed practice.

Being mindful of the need to create a class/object/hooks will keep us on the path of scalable and maintainable software.

Conclusion

It doesn't matter if you write code with a hook; software manageability is an ongoing task, and you should always be mindful of what could jeopardize it.

Let me know through comments. or on Twitter at @heypankaj_ and/or @time2hack

If you think this article is helpful, please share it with others.

Subscribe to the blog to receive new posts right to your inbox.