Show HN: Tired of logic in useEffect, I built a class-based React state manager

mjfisher

Just to sanity-check my reading of this: - Zustand exposes itself as a hook. - MobX does that observer-wrapper thing - Snapstate instead has an explicit writing step (`scoped()`) at the bottom of a component If so, I really quite like that. Kudos!

igor47

All the examples are fetching data from a server, and in such cases I think tanstack query already does all the hard part. I feel like people under-use react query and put too much state in their FE. This might be relevant if your app has some really complicated interactions, but for most apps they should really be a function of server , not client, state. Of course this exact reasoning is why I moved off react altogether and now use htmx in most of my projects

hungryhobbit

Javascript and classes go together like toothpaste and orange juice. All good JS programmers I know essentially pretend that classes don't exist in the language (or if they use them, they only do so rarely, for very niche cases). JS does not have classical OOP built in! It has Brandon Eich's prototypal inheritance system (which has some key differences), along with a 2015 addition to the language to pretend it has OOP (but really that's just lipstick on the underlying prototypal pig). If you use classes in JS, you're bound to be disappointed at some point when they don't behave like classical OOP. Most devs accept that and use more functional approaches (like factory functions) instead of OOP.

jemmyw

We have a similar style of react state manager that we use at Aha! https://github.com/aha-app/mvc I think the intent is very similar even though there are some structural differences: move the state and state logic out of the view to classes.

dsego

Sorry for being pedantic, but the first example could be rewritten to extract the pattern into a higher level hook, eg useNotifications. One way to simplify components before reaching for store libraries. The reusable hook now contains all the state and effects and logic, and the component is more tidy. function Dashboard() { const { user } = useAuth(); const {loading, error, notifications, undreadCount, markAsRead} = useNotifications(user); if (loading) return <Skeleton />; if (error) return <p>Failed to load: {error}</p>; return ( <div> <h1>Dashboard ({unreadCount} unread)</h1> <StatsCards stats={stats} /> <NotificationList items={notifications} onRead={markAsRead} /> </div> ); }

oDot

The problems OP tries to address are unfortunately a deep design flaw in mainstream frameworks like React and Vue. This is due to 2 properties they have: 1. They marry view hierarchy to state hierarchy 2. They make it very ergonomic to put state in components I've been through this endless times. There are significant ways to reduce this friction, but in the end there's a tight ceiling. This is why this kind of work feels like chasing a moving target. You always end up ruining something inherent to the framework in a pursuit to avoid the tons of footguns it's susceptible to. It's also why I moved to Gleam and Lustre (elm architecture) and bid those PITAs farewell

apatheticonion

Same: https://github.com/alshdavid-public/mvvm/blob/main/examples/...

confidantlake

Seems like a solution in search of a problem.

fiddeert

Still waiting for "I was tired of AI titles using the format 'I was tired of x, so I built y', so I built ..."

lateforwork

You can use React in an MVC framework, with React used to implement the 'V' in MVC. You can use class components, and the code becomes extremely simple. Business logic is moved to 'M' layer (models) and the 'C' layer (controllers) coordinates everything. No hooks or other messy stuff needed. In fact, React was originally designed to be used this way (as the V in MVC)! See https://github.com/Rajeev-K/mvc-router

000ooo000

What exactly abut MobX do you find too magical/implicit?