This content originally appeared on Go Make Things and was authored by Go Make Things
One of the most common arguments I’ve heard for using React over the years is that it adds structure to your code base and prevents people from writing spaghetti code.
I also believe that anyone who says that is lying (either to you or to themselves).
Let’s dig in!
Nested Dolls
React encourages nested components and passing properties from one component to the next.
import { TodoItem } from './components/TodoItem.js';
function TodoList ({items}) {
return {items.map((item) => {
return <TodoItem item={item} />;
});
}import { TodoComplete } from './components/TodoComplete.js';
import { TodoEdit } from './components/TodoEdit.js';
function TodoItem ({item}) {
return (
<li>
<TodoComplete itemID={item.id} />
{item.label}
<TodoEdit itemID={item.id} />
</li>
);
}import { FormAPI } from './components/FormAPI.js';
import { Completed, Incomplete } from './components/Icons.js';
function TodoComplete ({id}) {
// ...
}At first, this gives the illusion of structure.
But as your code base grows, and your components start calling components that call components that call components that call yet more components, you have a choice to make: keep them in one file, or split them.
If you keep them together, you have one very long file to read. If you split them up, you’re constantly jumping from one file to the next chasing down properties until you find what you’re looking for.
Functions on functions
React hooks encourage nest functions inside functions inside functions.
(Insert the Xhibit “yo dawg” meme here…)
It’s not uncommon to see stuff like this in a React code base…
function TodoComplete ({id, todo}) {
const [isCompleted, setIsCompleted] = useState(todo.isCompleted);
function handleSubmit (event) {
// ...
}
function handleClick (event) {
// ...
}
useEffect(function () {
// ...
})
return (
<form onSubmit={handleSubmit}>
...
<button onClick={handleClick}>Cancel</button>
<button>Complete</button>
</form>
)
}Maybe it’s just me but… this is not good code.
I realize this is just an opinion or personal preference, but having a bunch of functions all nested inside each other like that makes the parent function unruly. It’s harder to read and harder to reason about.
I’d much rather have code setup like this…
function handleSubmit (event) {
// ...
}
function handleClick (event) {
// ...
}
useEffect(function () {
// ...
})
function TodoComplete ({id, todo}) {
const [isCompleted, setIsCompleted] = useState(todo.isCompleted);
return (
<form onSubmit={handleSubmit}>
...
<button onClick={handleClick}>Cancel</button>
<button>Complete</button>
</form>
)
}But you can’t do that in React, because all of your functions typically rely on state that’s scoped inside the component function.
Spaghetti code is a people problem
This kind of stuff isn’t a React problem.
You can write code that looks like this with jQuery or Vue or Solid or Svelte or plain old vanilla JS.
We throw tooling at problems like this, but tooling is, at best, a band-aid. It doesn’t really solve the underlying problem.
If you want to stop spaghetti code, you’re better served investing in good documentation and developer discipline.
Like this? A Lean Web Club membership is the best way to support my work and help me create more free content.
This content originally appeared on Go Make Things and was authored by Go Make Things
Go Make Things | Sciencx (2025-01-31T14:30:00+00:00) Spaghetti code is a people problem. Retrieved from https://www.scien.cx/2025/01/31/spaghetti-code-is-a-people-problem/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.