React Hooks (And Other Front End Composition APIs) And Code Maintainability

A real world use case (with code samples) illustrating how composition APIs in front end frameworks are amazing

Which looks more organized to you?

Note: I will only name React Hooks in this post, but know that these principles apply to other frameworks with similar APIs (e.g. Vue 3’s Composition API) as well. In fact, Vue’s creators have already covered this topic!

React Hooks are old news, but I wanted to cover a real use case that I had recently when working on my website and give a concise example.

Background

I was making a paginated list in Vue’s composition API. The components are split up in this way:

• PaginatedList: holds state for the list and page in order to render a subset of the list
• Paginator: renders buttons for switching to adjacent pages, jumping to the front and back, and an input to allow jumping to an arbitrary page. It is a mostly controlled component since its state is reliant on the props passed in

By the time I was finished, I looked at the code and was inspired to write this up. It’s too impactful not to share.

The Sample Code

Below is a simplified implementation of a paginated list that I wrote up in React in both the old Class API and the new(-ish) React Hook API.

The Not-So-Big Deal

The Paginator implementations (PaginatorWithClass and PaginatorWithHooks) only differ slightly:

• The hook API uses “useEffect()” to handle the state change involved with a prop change by passing in the page as a dependency
• The class API uses “componentDidUpdate” to handle the same state change, but requires an explicit check on the page prop or else it would prompt an infinite recursive update-componentDidUpdate loop.

Personally, this already gives a compelling reason to use hooks. Imagine a more complex controlled component with multiple state values that must be updated on prop change. For hooks, we can place a full list of dependencies at the end of a “useEffect()”, which is much easier to humanly parse than a sequence of if and else if statements that a class implementation will need to prevent infinite loops.

But in case you aren’t sold yet…

The Big Deal

The Paginator List implementations are where the most important differences are:

• The class API requires state to store “itemsDisplayed” and logic that recalculates itemsDisplayed
• The hooks implementation outsources both to a separate method, “usePaginator()”

This is a big deal. Imagine if this was a project rather than a Codepen snippet where we have Paginator and PaginatedList components in separate files. We can place “usePaginator” in the same file as the Paginator component, meaning that the hook implementation isolates this behavior into one file. The class API couples pagination logic with consumers of pagination, rather than with pagination itself.

A second and related effect — imagine creating an ExternalDataPaginatedList where the list is fetched from a server on demand rather than rendering a subset of a fully loaded list. Creating a new Paginated List using classes means duplicating the state variable itemsDisplayed and recalculation code on page change. Creating a new Paginated List using hooks means calling “usePaginator()” with the new functional component — we simplify the act of consuming existing code and drastically reduce the amount of repetition, especially in future development.

The Takeaway

As projects get bigger and (assuming the project is being designed well) logic gets component-ized into reusable code chunks, code organization becomes more and more important. By minimizing code repetition and isolating behavior, hooks allow the code to have a predictable structure that lets future engineers do less jumping between files and develop much faster.

So the takeaway is… use hooks. Future you will thank you.