Discussion
Why I Built Snapstate
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
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 componentIf so, I really quite like that. Kudos!
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.
epgui: For clarity, what do you call "classical OOP"?(disclaimer: FP all the way, regardless)
hungryhobbit: Essentially `new Foo()`, where `Foo` can be a subclass of `Bar` that inherits properties in the same way we all learned in our Java (or whatever actual OOP) language.JavaScript gives you a class syntax that lets you make classes and extend them from each other, and for the most part they will work the same way as a class from a language like Java ... but some things won't.You can either become an expert on prototype chains, and how JS actually implements OOP (differently from Java) ... or you can just write factory functions instead of classes.
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 hierarchy2. They make it very ergonomic to put state in componentsI'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 running 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 Lutee (elm architecture) and bid those PITAs farewell
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> ); }
whizzter: Far cleaner, how is testability though?
SketchySeaBeast: Very easy - mock the useNotifications and you can easily see all the behaviour by changing three properties.
andrewstuart: I use no state manager at all.Local component state is great.I use events for all other cross application communication.Prop drilling is limited to one level - for making components that make children.
kretaceous: Can you give examples of how they are different? I've only done OOP in JS so I'm not aware of what I'm missing or what's supposed to be different.
dsego: It's not just react query, you can make a quick useFetch and useMutation hooks (or claude can), it's not that complex. If you don't need more advanced features (eg caching), you can easily cut down on 3rd party dependencies. import { useState, useEffect } from "react"; function useFetch(url) { const [data, setData] = useState(null); const [loading, setLoading] = useState(true); const [error, setError] = useState(null); useEffect(() => { const controller = new AbortController(); fetch(url, { signal: controller.signal }) .then((res) => res.json()) .then((json) => { console.log("Data:", json); setData(json); }) .catch((err) => { if (err.name !== "AbortError") { console.error("Fetch error:", err); setError(err); } }) .finally(() => setLoading(false)); return () => controller.abort(); }, [url]); return { data, loading, error }; } function App() { const { data, loading, error } = useFetch("https://jsonplaceholder.typicode.com/todos/1"); if (loading) return <p>Loading...</p>; if (error) return <p>Error</p>; return <pre>{JSON.stringify(data, null, 2)}</pre>; }
apatheticonion: Same: https://github.com/alshdavid-public/mvvm/blob/main/examples/...
