98% of Developers Use React as a Framework, Not a Library

🌱 Note: This post is still being updated for clarity and utility. Short on time this week.

What’s the difference between a framework and a library?

A framework is something that you plug your code into.

A library is something that you plug into your code.

If that’s the case, then 98% of developers use React as a framework instead of a library.

Control centers

In Responsibility-Driven Design, there’s this idea of control centers.

Control centers are the parts of your codebase tasked with coordination and control.

• Coordination = handling events, reacting to them, relaying events to others
• Control = directing the action of lower-level objects, delegating work.

Every application has at least one place that does coordination and often several places that handle control (hence why we tend to have multiple controllers in MVC).

Most developers let React handle coordination and control

The React documentation and thought leadership today urges you to write the majority of your code within React, using custom Hooks as the key place to put things that have to do with control, data, rules, processes, and so on.

This is great for getting started, but essentially, we’re doing the exact same thing we try to avoid doing on the backend: creating an anemic domain model.

Coordination and control are application layer concerns

Just like application service use cases and command handlers are application layer concerns in backend programming, on the frontend, code that determines what happens after a click or a keypress - these too, are application layer concerns.

What happens when we put coordination and control inside of React?

I can think of a few different implications, but the key one is that we have less testing options.

Because you need React to spin up and test your application (and domain) layer code, the idea of testing your core functionality in isolation isn’t possible. In fact, it's borderline impossible.

How do we fix this?

• Decouple from the library and framework
• Create your own control center — To create your own control center, you need at least one Coordinator and as many Controllers as necessary (these are synonymous to application-layer Use Cases though I’ve also used the word Interactor and describe the type of logic they encapsulate as Interaction Logic).

I will say more on exactly how to do this in another post, but for now, see the following Object Stereotypes.

The Coordinator: Coordinators are one of two objects most responsible for determining how control works in our applications. The Coordinator stereotype has one real purpose: to pass information to other objects so that they can do work. This is effectively the Observer Pattern. While it’s common practice to use something like Redux to create this, it’s not necessary. You can have something like this working in less than 20 lines of code.

The Controller: In RDD, the Controller stereotype behaves the same way as the Use Case pattern. The stereotypical responsibility held by a Controller is to act as a higher-level (application-layer specifically), declaratively focused object that coordinates the behaviour of lower-level concerns. The Controller pulls other objects together and makes them collaborate with each other. They can be modelled as Features.