I recently saw a comment on Hacker News comparing React hooks with multiple inheritance in C++. I thought this was an interesting analogy and wanted to expand on it a bit.

Hooks are not functional

First of all, React hooks are functions, but they are not “functional.” They’re better thought of as an escape hatch for non-functional behavior in function components.

Consider the following function component:

function TextInput({ value, onChange }) {
  return <input type="text" value={value} onChange={onChange} />;
}

This is a pure function:

1. Given the same input, it always returns the same values.
2. It has no internal state.
3. It has no side effects.

But what if we want the function to have internal state or side effects? Well, that’s what hooks are for:

function TextInput({ defaultValue, isValid, onChange }) {
  const [value, setValue] = useState(defaultValue);
  useEffect(() => {
    if (isValid(value)) {
      onChange(value);
    }
  }, [isValid, onChange, value]);
  return <input type="text" value={value} onChange={(v) => setValue(v)} />;
}

In the above example, we have internal state via the useState hook, and side effects via the useEffect hook. Our function component isn’t so functional anymore.

React hooks are like inheritance

This is the kinda cool part. At least, I think so!

Take a step back from React for a moment and imagine you’re writing code in an Object Oriented language like C#, Java, etc. These languages have something called inheritance, where a class can inherit functionality from another class.

What do you get when you inherit from a class?

1. State. The inherited class can “own” some state, whether private or public. A Counter class might have a piece of state called currentValue. The state is initialized by a constructor and is associated with a particular object.
2. Methods. The inherited class can have methods, which are just functions that encapsulate functionality associated with an instance of the class. These methods frequently read/write the object’s state.

Depending on the language, there are some other things you get as well (like “is-a” semantics when checking the object’s type, polymorphism, dynamic dispatch, etc.), but those are tangent to the point.

Now let’s look again at a React component that uses a hook:

function Counter({ initialValue }) {
  const [value, setValue] = useState(initialValue ?? 0);
  return <button onClick={() => setValue(value + 1)}>{value}</button>;
}

What is useState bringing to the table here? Even without looking at the implementation, we can infer a few things.

1. It’s bringing state — specifically, the value variable is a piece of internal state that Counter can access. The state is initialized to a default value (which looks like a constructor if you squint), after which it’s just… there. Even if you change the initialValue prop later, the internal state will not change.
2. It’s bringing methods, kind of. The setValue function is like a method because it exists to modify some internal state.

The parallel becomes really strong when we actually compare a useCounter hook with a Counter class:

function useCounter(initialValue) {
  const [value, setValue] = useState(initialValue ?? 0);
  const increment = () => setValue(value + 1);
  return [value, increment];
}

Versus:

class Counter {
  private value;

  constructor(initialValue) {
    this.value = initialValue ?? 0;
  }

  public increment() {
    this.value += 1;
  }

  public getValue() {
    return this.value;
  }
}

Both the class and the hook are encapsulating some state and exposing an interface that supports incrementing a value and viewing the current value.

Multiple hooks = multiple inheritance

Normal examples of inheritance typically have one base class and multiple subclasses that inherit from it:

• Define a class called Shape
• Create subclasses Circle, Square, etc.

But there is actually a generalization of single inheritance that allows a single class to inherit from multiple parents, aptly named multiple inheritance.

With multiple inheritance, you can define base classes that encapsulate commonly used functionality and reuse them in your subclasses.

For example, you could define two classes:

• A Counter class that encapsulates counter state.
• An HttpClient class that encapsulates HTTP client behavior.

And you could use both of those in a EventTracker subclass (pseudocode):

class EventTracker extends Counter, HttpClient {
  public increment() {
    this<Counter>.increment();
    this.sendRequest('/count', this.getValue());
  }
}

Does this look familiar? In React, we could define this as a hook:

function useEventTracker() {
  const [value, increment] = useCounter();
  const { send } = useHttpClient();
  useEffect(() => {
    send(value);
  }, [send, value]);
  return increment;
}

Like, but unlike

So, are hooks “the same as” multiple inheritance? No. They solve similar problems, but there are differences.

The biggest reason for the differences is that hooks are ultimately just functions, and they are used in function components which are also just functions. In contrast, the multiple-inheritance situation is working with classes and objects, which are more complex.

All you can do with a function is just call it. It doesn’t have methods or properties. It doesn’t really have a nominative type. And, whatever functions are called within the parent function are totally hidden.

You can’t check if useEventTracker is an “instance of” useCounter like you can with the EventTracker and Counter classes.

This also means that polymorphism and dynamic dispatch, which are properties of objects associated with method calls (and property access, which is a similar thing), just aren’t applicable to plain functions.

Actually, this is kinda nice. Polymorphism and dynamic dispatch are powerful but also notoriously confusing in some situations.

I won’t say hooks aren’t confusing, but they manage to avoid some of the frustrating bits that come up when dealing with multiple inheritance in the wild.

Conclusion

I’m not trying to argue that hooks are good or bad, here.

They do solve a problem that’s not easy to solve with pure functions (even if it is possible), and do so without reintroducing all the pitfalls of classes and inheritance.

But on the other hand, complex usage of hooks quickly gets confusing, and they have some parts (like dependency arrays for useEffect et al.) that just feel weird to use.

I like hooks (in particular, I like how I can write custom hooks like useAppState or useApi to encapsulate app-specific behaviors). But like them or hate them, we’re stuck with them as long as we keep using React.