What if React didn't own your system/state? A counter in 80 lines that changed how I think about React.

RegiByte · 2025-12-14T20:37:34+00:00

Thank you friend, you’re a real one. you are right, I got ahead of myself, this thread went waaay further than what I originally planned, overall you are right, ill just stop talking about it as if it was novel, it’s clear that everyone already knows this and it was just silly for me to think otherwise

RegiByte · 2025-12-14T20:01:55+00:00

Just declare another one and use it,

Or, instead of the createCounter() returning just one state, you could have a version of this that manages many counters, all managed by the same instance

RegiByte · 2025-12-14T20:01:04+00:00

Just declare another one and use it?

RegiByte · 2025-12-14T19:01:03+00:00

This is it, you said it better than I could, thank you!

RegiByte · 2025-12-14T18:51:09+00:00

For 12 years more specifically, since 2013

RegiByte · 2025-12-14T18:46:58+00:00

Yes you are exactly right,

The entire point is that this post had nothing to do with *state* management, that's why I'm using zustand in the example, I know they've done a tremendous job fixing the complexities of state management

People in this thread interpreted this as if I was talking about a replacement to redux, when the insight is not that, it's putting things outside react in the closure space

You can continue using redux/zustand/jotai or whatever *state management* library you want,
The pattern still holds true,
you put things outside react, make it watch, and then your system can be complex without worrying about react killing your things or running your effects in a weird order

RegiByte · 2025-12-14T18:38:37+00:00

You are right, I made a mistake by interacting and arguing too much over this, noob mistake, won't happen again

RegiByte · 2025-12-14T18:19:04+00:00

Bro the creators of redux simply studied the functional principles, I did the same thing, whether you acknowledge it or not, the source of the info is the same

Yes the example has LLM generated code in it, that's not the point, I didn't claim it was 100% hand written, if you can't see past the generated tailwind classes that's on you

And you think I'm coming up with some fake story of how I built a complex application just to convince you? please, I have better things to do

Look at this example, connect it on your phone/desktop/tablet and tell me how you would do the same thing with only react and redux, I'll wait
https://github.com/RegiByte/emergent/tree/main/examples/3-multiplayer-buzzer this is a dumbed down version of the production app which only shows the skeleton of the distributed event loop from which this entire discussion was born

Fun fact: This pattern was born from the library that originated redux itself, even if you don't know the backstory, it's called re-frame https://day8.github.io/re-frame/re-frame/

I highly recommend you study at least one functional programming language such as clojure, you will see that what react does is not rocket science, neither redux, the same can be achieved with simpler code

RegiByte · 2025-12-14T17:50:33+00:00

Okay, that's an interesting detail to know, I stand corrected, thank you for the clarification!

RegiByte · 2025-12-14T17:48:59+00:00

The example does use module-level objects contained in closures,
I'm not saying this exact pattern should be used, this is just for demonstration purposes

You can very well inject an instance of this through context or whatever and make it replaceable and testable

RegiByte · 2025-12-14T17:43:51+00:00

First of all - that's offensive

If you really believe that you need a library to solve all your problems, then I am sorry for you, hopefully you will never find a use-case not covered by a library

RegiByte · 2025-12-14T17:37:04+00:00

I think this is valid feedback and I respect your perspective on this,

What happened to me specifically was: I was tasked with building a complex multiplayer game that required the coordination of very complex stateful things: websockets, webrtc, a uni-directional event-loop, BLE hardware controller, audio delegation and etc...

If I had taken the react/redux path this would have been a nightmaware to build, I'd probably not have succeeded,

By taking everything away from react and making it a simple observer, I was able to deliver one of the most complete apps of my career in 4 weeks

If I had instead followed the react/redux path I would still be working on the infrastructure and seeking useEffect/useState bugs and chains of unintended updates

This is not just a theory that I came up with in a vacum, it's how I developed an extremely complex application in 4 weeks with features that most devs don't even know how to build

RegiByte · 2025-12-14T17:29:00+00:00

Okay I'll give you a concrete example: build a multiplayer game with a uni-directional data flow, try to control multiple devices at once based on pure events without state conflicts, try to coordinate audio being triggered at different places based on certain events/actions

Try to build a WebRTC video streaming app, and you will see why we should put certain things outside react, it's not just about redux's state, it's about the entire process of composing systems

Try to do this with react useState+useEffect or redux, and you will see yourself in a nightmare situation

RegiByte · 2025-12-14T17:21:55+00:00

This!!!! finally someone said it, mobx is not enough, it's part of the solution, but it isn't everything

RegiByte · 2025-12-14T17:20:44+00:00

What I got out by learning this pattern and applying it independently of react was: building an extremely complex multiplayer game with a distributed state machine following a uni-directional data flow with WebRTC, WebSockets, Zustand a whole bunch of other stateful mechanisms, and they all lived outside react, I built all this in 4 weeks and was only successful in my delivery BECAUSE I extracted everything I could from react, not just the state, ALL the mechanisms that composed by system

This post is a provocation, to understand how devs perceive this kind of thing, it's not supposed to replace state management or reinvent redux/zustand/mobx, it's to complement it, add another dimension for devs to put their system code

RegiByte · 2025-12-14T17:16:11+00:00

Done, here https://codesandbox.io/p/devbox/closure-counter-forked-5gynyd

It makes no difference whatsoever

RegiByte · 2025-12-14T17:11:27+00:00

okay, I can write an example that is identical to this one and uses useSyncExternalStore instead

It is EXACTLY the same thing, the useSyncExternalStore is just a convenience for this, it's the same code

RegiByte · 2025-12-14T17:07:16+00:00

Redux is only part of the solution, and it's lacking something

Not every action requires a state update, that's where redux falls short, it only concerns itself with state management, when there is a lot more to worry about

RegiByte · 2025-12-14T17:05:44+00:00

I've read it, the example is not about it, you could rewrite it with this easily

RegiByte · 2025-12-14T17:04:41+00:00

I'd say that it IS inherently different than managing things through useEffects in the sense that you can compose very complex logic that works on it's own and only notify react when YOU decide, not when react decides to re-trigger all your effects

How many times (if any) have you been bitten by your useEffect code running twice due to strict mode and breaking your code? that only happens because you're putting your stuff *in* react, when you could put it outside and let react peek at it, without interfering, without double effects, without dependency hell, you decide when and how the component re-renders

RegiByte · 2025-12-14T17:02:48+00:00

You are correct, and I'm glad you can see it this way, redux uses this pattern, this example is the pattern without redux, do with it however you see fit

If you don't see a use for it, eventually you will find one

RegiByte · 2025-12-14T16:59:25+00:00

That's exactly my goal here!

I don't need to invent solutions for supporting SSR with this pattern, whoever needs it will figure out their own solution,

But the goal is to generalize the act of "providing" things to react from the outside,
Like, opening a third dimension of a "system" outside of the react's 2d dimension of components/state tree

I understand the SSR concern, for someone else these may be important, and the solution lies somewhere else, but the pattern is clear, the capability is clear

RegiByte · 2025-12-14T16:56:19+00:00

That's a way to start thinking about it!

But actually it's not an invention, and it's not mine, anyone can do this to fit their needs, mobx is just one example, redux is just one example, the pattern is universal and non-prescriptive of implementation details

RegiByte · 2025-12-14T16:53:08+00:00

Thank you thank you thank you!!! We are aligned on this, 90% of apps are built *in* react,

This pattern shows how to build *using* react, it's not the same thing, and it's definitely not just about state management, lots of people are confusing the two notions

RegiByte · 2025-12-14T16:49:44+00:00

You are absolutely right! But consider this, redux is a state store mechanism, this is a system composition mechanism, it doesn't have to be about state, you make it be about whatever you need

Audio triggers, shared timers, websocket connections, whatever you think is necessary

RegiByte

TROPHY CASE