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.
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).
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.
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.
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.
- 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.
Liked this? Sing it loud and proud 👨🎤.
Stay in touch!
Enjoying so far? Join 15000+ Software Essentialists getting my posts delivered straight to your inbox each week. I won't spam ya. 🖖
View more in Frontend
You may also enjoy...
A few more related articles
Software Design and Architecture is pretty much its own field of study within the realm of computing, like DevOps or UX Design. Here's a map describing the breadth of software design and architecture, from clean code to microkernels.
Learn how to use DDD and object-oriented programming concepts to model complex Node.js backends.
Want to be notified when new content comes out?
Join 15000+ other Software Essentialists learning how to master The Essentials of software design and architecture.