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

Last updated Sep 4th, 2022
React is a view layer library but most developers use it as a framework. Let's look into why that is and the implications of it.

🌱 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).

Untitled

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.

Coordinator.svg

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.

Controller.svg



Discussion

Liked this? Sing it loud and proud 👨‍🎤.


3 Comments

Submit
Dmitro
18 days ago

Looks interesting we need real code examples

Victor
18 days ago

When will you launch front end ddd course?

jakub
18 days ago

the links are pointing at the notion version of this article


Stay in touch!



About the author

Khalil Stemmler,
Developer Advocate @ Apollo GraphQL ⚡

Khalil is a software developer, writer, and musician. He frequently publishes articles about Domain-Driven Design, software design and Advanced TypeScript & Node.js best practices for large-scale applications.



View more in Frontend



You may also enjoy...

A few more related articles

Client-Side Architecture Basics [Guide]
Though the tools we use to build client-side web apps have changed substantially over the years, the fundamental principles behind...
GraphQL Schemas vs. RESTful DTOs
GraphQL schemas serve a similar purpose to RESTful DTOs. One of the main differences is tooling. In this post, I aim to strengthen...
GraphQL's Greatest Architectural Advantages
There's a lot of advantages to using GraphQL instead of REST on your server, and there's a lot of advantages to using Apollo Clien...
Why Event-Based Systems? | Enterprise Node.js + TypeScript
There are so many reasons why event-based systems are the standard for large-scale enterprise applications like GitHub, Facebook, ...

Want to be notified when new content comes out?

Join 15000+ other developers learning about Domain-Driven Design and Enterprise Node.js.

I won't spam ya. 🖖 Unsubscribe anytime.

Get updates