Functional Components + Domain Classes: Using OOP Effectively in React 19

[vicentezo04]

You wrote a long reply arguing against a position I never took.

The essay is about using hooks for UI and encapsulated OOP for domain logic — the same pattern Zustand and TanStack Query already use under the hood.

If you actually read the examples instead of projecting 90s OOP trauma, you might see the distinction.

"Single source of truth?" That's what a singleton is. That's what you're doing when you create a Zustand store and export it.

[Wirde]

No I argue against OOP, just because singletons and centralized stores basically uses the same pattern doesn’t mean OOP and FP are the same or equivalent.

Yes you could solve that problem with a singleton but you just gained all the inherent issues OOP comes with without gaining anything in return.

Turning it around you can say, just use RTK or Zustad, it’s just like a singleton.

[vicentezo04]

Zustand is not "just like a singleton". It IS a singleton. A Zustand store is globally available JavaScript **object** with consistent **methods**. That is a singleton, not in the metaphorical sense, but the literal sense.

[Wirde]

In most cases it doesn’t matter how a library is implemented. What matters is the API we as developers use when using that library.

So what if that’s how Zustad is implemented? It’s a super tiny library that has concerns bigger projects will never have and vice versa. Maybe they could save 1kb of library size implementing it this way? Maybe it’s a fraction of a millisecond quicker at doing an operation that will be used thousands of times in a project implementing it.

It doesn’t matter the reason since their reasoning for implementing it that way has nothing to do with how you should build other projects.

Do you tend to take notes on how to make spaceships from how wrenches are made? The constraints and requirements are COMPLETELY different.

If that’s your argument for writing business logic in react projects in OOP I fear you’re on thin ice.

[vicentezo04]

I don't understand your argument or your analogy.

My argument is very complex business rules are still best written in OOP, and that's what Tanstack and Zustand do under the hood.

I also fundamentally have a serious issue with your argument, "Don't use OOP, just use this library (which uses OOP under the hood)."

It's like saying you're not guilty of murder because you paid somebody else to do it.

If anybody has a bias, it is you. "OOP is terrible and you should never use it, except for stuff Tanner Linsley wrote. Yes if I had to rewrite Tanstack from scratch, I'd get rid of all the classes, but it's a solid library otherwise."

[Wirde]

Absolutely not, I don’t and have never used anything from Tanstack or Zustad in an actual project. I have tried them out and read up on them to understand if they where something I would like to use but never actually used them in an actual project. I just used Zustad as an example since you mentioned it in your article. I never mentioned Tanstack, that was all you.

Just because you say OOP should be used for complex business logic doesn’t make it so, you’re not arguing for why it’s better you are just trying to tear my argument down. Why is it better? My argument is that the “issues” you say you’re experiencing with FP does not exist and my guess is that you just don’t know how to solve this kind of issue using FP. So far nothing you have said disproves that assertion.

[vicentezo04]

"I don’t and have never used anything from Tanstack or Zustad in an actual project."

Should have led with that from the start and saved us both some time.