Unpacking Tao of React #1

Imagine you're a front-end dev and you don't know anything about software architecture. Now, imagine you have an interview tomorrow at exactly 7:32 AM and you need to absorb some core concepts—fast.

While browsing the internet, you stumble across a specific book—but unfortunately, you don't have enough time to read it (after all, the interview is literally tomorrow at 7:32 AM 😵‍💫).

If that sounds like you, this article (and the next ones) are for you.

The book I'm talking about is Tao Of React by Alex Kondov.

I decided to re-read it and share a few thoughts on how using some of its concepts worked for me in production. I'll go through specific topics—from folder structure to external libraries and state management decisions.

Let's dive in!

---

1 - Architecture

initially just folder organization lol

1.1 - The common module

The idea is simple: if you'll reuse it in more than one place, toss it in a common folder.

Not just components—hooks, helpers, utils, anything reusable. Abstract it and centralize.

Why?

To avoid duplication and make maintenance easier.

---

1.2 - Absolute paths

This might sound like nitpicking, but once your project scales, you'll be grateful for following this.

Avoid this:

import { foo } from "../../../../common/helpers/foo";

Use this instead:

import { foo } from "@common/helpers/foo";

Why?

Clarity and flexibility. If you ever refactor folder structures, your imports stay clean and understandable.

---

1.3 - Wrap components inside folders

Think about how you organize your clothes—you don't mix shirts and pants randomly.

Now think about your components the same way.

What's easier to understand and maintain?

❌ Bad:

✅ Good:

---

1.4 - Route/Module structure

Simple rule: Separation of Concerns.

Each page (or module) should only contain stuff related to itself.

If you're in the home page folder, there shouldn't be any code about the dashboard there.

Easy.

---

1.5 - Modular dependencies

Here's where I respectfully disagree with Alex Kondov.

He mentions the Rule of Three: it's okay to repeat something up to three times—on the third time, refactor and abstract.

But I say:

If you're using something from module X in module Y—it's already reusable. Move it to common. Why wait?

---

1.6 - External components

Imagine using a UI library's Button like this:

<Button>Click Me</Button>

Suddenly, the library maintainers change it to:

<Button placeholder="Click Me" />

Now you have to refactor every instance.

Solution?

Create a wrapper around external components. So if the API changes, you only need to update it in one place.

Yes, the example is exaggerated—but the lesson stands.

---

What's next?

In the next article: How to create a module efficiently?

Basically, a step-by-step to not mess things up when modularizing your app.

---

That's it for now!

Hope you enjoyed the read—I'm writing this the way I wish someone had explained it to me. Feedback is welcome ✌️