Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The new wave of React state management

frontendmastery.com

Post reply on HN
Print view View original

221–230 of 310 posts

Re: The new wave of React state management

#221

Post by lvass »

robocat wrote: post #178
dageshi wrote: post #15

After reading the "Grug Developer" article recently, I've been thinking of frontend development as "The Plane of Eternal Complexity Demons".

JavaScipt on the browser is cursed[1]. 1. There is no standard GUI library, as per article. A GUI can be as arbitrarily complex as you wish, and every different frontend system is a unique GUI system deployed in JavaScript, usually using HTML for the view drawing primitives* and events for input. The complexities of GUI library design bubble up to developers who are implementing their own tweaks or combinations of a…

At least in AI, what happened to lisp was being replaced by Python. What do you presume happens to JS in this case? WASM frameworks are likely to have the same problems. Stuff like Phoenix Liveview can be rather standard but limited in scope.

Re: The new wave of React state management

#222

Post by wokwokwok »

ezekiel11 wrote: post #151

I ditched React/Redux for Vue 3 & Pinia and my god, what a world of a difference. Everything is intuitive and I am not googling days to fix tooling issues, or having to do it the React/Redux way which was honestly overly engineered and non-productive. Frontend shouldn't be complicated and we've been lied to, you are not Facebook, you don't have billions to throw at engineering, you must pick the path of list resistan…

I'm pretty surprised.

I recently did the same, and hand's down, the vue ecosystem is weak.

Vue is difficult to work with (unable to render content without a functional component wrapper, poor support for style libraries like tailwind), and the state management ecosystem is fractured between vuex and pinia. Worse, much of the help online is for old versions (vue2). Storybook 'out of the box' is broken and doesn't work at all (unable to resolve '@/...' imports).

It's been painful.

> Everything is intuitive and I am not googling days to fix tooling issues

That has not been my experience; I spent literally 3 days customizing my storybook install to make it work, and digging through 'try this...' threads on https://github.com/storybookjs/storybook/issues/11989

Re: The new wave of React state management

#223

Post by okhobb »

pcthrowaway wrote: post #194
frosted-flakes wrote: post #183

Earlier quoted context omitted.

React-Query is very aggressive about refreshing the cache by default, including whenever the browser receives focus, on a set schedule, and automatically retrying failed queries multiple times, these can all be disabled. If any queries use the same key they should share data, but I haven't experimented with it enough to learn all its intricacies.

Sure, all the other settings work fine (refresh on focus, failure retry, etc.), I just would have hoped to limit the requests made when the same data is requested in many different places.

Try checking out the options:

      refetchInterval: false,
      refetchOnMount: false,
      refetchOnWindowFocus: false,
      refetchOnReconnect: false,
      staleTime: Infinity,
I was similarly surprised at how 'chatty' react-query was by default, but changing these defaults quieted it down. Great library though, and I understand the argument for these defaults.

Re: The new wave of React state management

#224

Post by mikewhy »

acemarke wrote: post #195
mikewhy wrote: post #193

Earlier quoted context omitted.

Have you considered something like "selector based side effects"? https://github.com/mikew/redux-easy-mode#selector-based-side... . The difference is most side effects are based around when an action is dispatched, but I wanted to know when things _change_. It's possible to do the same thing with a react component + useEffect, but I thought a pure-redux solution would better fit the spirit of Redux.

Yes, you _can_ actually do that with the listener middleware! We specifically designed that to be possible. When you add a listener entry, there are four options to specify how the middleware knows when to run that listener: 1) `type`: an action type string; 2) `actionCreator`: an RTK action creator function like `todoAdded`; 3) `matcher`: an `(action: AnyAction): action is MyAction => boolean` type guard; and 4) `pr…

Yup! I'm aware, it's mostly an exercise I wrote after trying RTK.

It's a combination of two other Redux helpers I've been using for years before RTK existed. All mentioned in the "see also" section.

Re: The new wave of React state management

#225

Post by dqpb »

tunesmith wrote: post #209

I still find the whole subject so frustrating. Being a backend developer that has since out of necessity had to transfer to being a frontend-architect for a team of confused React developers, I'm struck with how the momentum of frontend development quickly leads to very complex state machines. Backend development hasn't tended to require this - you query information, perhaps you transform it, you return it. But with…

> Backend development hasn't tended to require this - you query information, perhaps you transform it, you return it.

Maybe the backend of a crud app is fundamentally simpler than a user-facing UI.

Re: The new wave of React state management

#226

Post by nyanpasu64 »

LAC-Tech wrote: post #184

I think the obsession the react space has with "state management" is a by-product of how incredibly convoluted reacts rendering is. The other reason is a lack of exposure to how other technologies for GUIs have handled state for decades. Maybe look outside the react bubble and see how many of these "issues" just disappear when you stop acting like react is some fundamental particle of the web.

Frankly I feel state management is a difficult task on desktop apps as well, to the point that tracking spaghetti-shaped causation and control flow is beyond my mental abilities. Qt itself as well as many apps are rife with redundantly calculating state or redrawing GUIs when changing the same value multiple times, or changing two values which both affect an outcome (my StateTransaction pattern mostly alleviates this issue with a set of dirty bitflags and recomputing all state dependent on those bits, though the reactivity system is currently hard-coded and statically dispatched, and generalizes poorly to open-ended state or managing the local state of many dialogs of the same type). And one of the craziest errors caused by witnessing malformed intermediate values is https://github.com/Dn-Programming-Core-Management/Dn-FamiTra..., where a sloppily-written "load document" function redrew the UI in the middle of mutating document state, causing the GUI to crash after observing a broken invariant.

It saddens me that so much of research in developing better state management techniques is in such a bloated and dependency-laden environment as JavaScript on the web. I like QML's reactivity system, but its evaluation engine is JS-based, dynamically-typed, and dynamically-scoped, and the UI engine itself is a buggy mess. And GTK4's list APIs promise to be better than the clusterfuck of Qt Widgets/Quick's QAbstractItem{Model/View} system (which abstracts poorly over list/column/tree collections, and widget-internal, cross-widget, and cross-application drag-and-drop), but I haven't tried that either.

Re: The new wave of React state management

#227

Post by ishitatsuyuki »

wokwokwok wrote: post #222
ezekiel11 wrote: post #151

I ditched React/Redux for Vue 3 & Pinia and my god, what a world of a difference. Everything is intuitive and I am not googling days to fix tooling issues, or having to do it the React/Redux way which was honestly overly engineered and non-productive. Frontend shouldn't be complicated and we've been lied to, you are not Facebook, you don't have billions to throw at engineering, you must pick the path of list resistan…

I'm pretty surprised. I recently did the same, and hand's down, the vue ecosystem is weak. Vue is difficult to work with (unable to render content without a functional component wrapper, poor support for style libraries like tailwind), and the state management ecosystem is fractured between vuex and pinia. Worse, much of the help online is for old versions (vue2). Storybook 'out of the box' is broken and doesn't work…

> poor support for style libraries like tailwind

Can't relate. Tailwind works fine with anything that supports PostCSS. I run it with Vite and there's zero issues.

> the state management ecosystem is fractured between vuex and pinia

This is also just not true. Pinia is officially replacing Vuex as the recommended store library for Vue [1]. They're also vastly similar in how they do things, so the knowledge transfer over from Vuex to Pinia. And Pinia just address most of the design goals mentioned in the article in the most simple way.

As for Vue 2 -> 3 transition, lots of the larger UI frameworks in the ecosystem is struggling to migrate, despite lots of efforts on the compat layer to smooth the transition, which is a bummer. But as long as you're not doing those sophisticated things, Vue 2 examples should work out-of-box on Vue 3 as well. There are surely less resources for the composition API, but the official introduction guide has been good enough in my experience.

[1]: https://vuex.vuejs.org/#what-is-vuex

Re: The new wave of React state management

#228

Post by Rapzid »

wokwokwok wrote: post #222
ezekiel11 wrote: post #151

I ditched React/Redux for Vue 3 & Pinia and my god, what a world of a difference. Everything is intuitive and I am not googling days to fix tooling issues, or having to do it the React/Redux way which was honestly overly engineered and non-productive. Frontend shouldn't be complicated and we've been lied to, you are not Facebook, you don't have billions to throw at engineering, you must pick the path of list resistan…

I'm pretty surprised. I recently did the same, and hand's down, the vue ecosystem is weak. Vue is difficult to work with (unable to render content without a functional component wrapper, poor support for style libraries like tailwind), and the state management ecosystem is fractured between vuex and pinia. Worse, much of the help online is for old versions (vue2). Storybook 'out of the box' is broken and doesn't work…

For state MobX works largely fine with Vue as long as you don't need libs that rely on Vue's observables.

It's my preferred go-to for Vue and React. Also opens the interesting possibility of supporting React and Vue components off the same stores..

Re: The new wave of React state management

#229

Post by tunesmith »

dqpb wrote: post #225
tunesmith wrote: post #209

I still find the whole subject so frustrating. Being a backend developer that has since out of necessity had to transfer to being a frontend-architect for a team of confused React developers, I'm struck with how the momentum of frontend development quickly leads to very complex state machines. Backend development hasn't tended to require this - you query information, perhaps you transform it, you return it. But with…

> Backend development hasn't tended to require this - you query information, perhaps you transform it, you return it. Maybe the backend of a crud app is fundamentally simpler than a user-facing UI.

That is one possible explanation, sure. But more than inherent complexity, it's also about whether there are sufficient guardrails and best practices in place to help manage that complexity.

Re: The new wave of React state management

#230

Post by hakfoo »

tunesmith wrote: post #209

I still find the whole subject so frustrating. Being a backend developer that has since out of necessity had to transfer to being a frontend-architect for a team of confused React developers, I'm struck with how the momentum of frontend development quickly leads to very complex state machines. Backend development hasn't tended to require this - you query information, perhaps you transform it, you return it. But with…

That's always something I've found weird.

There are things that are "global state", at least in the sense that you're likely to care about them in a hundred disparate places. If you're writing a UI, odds are at some point you're going to want to see "current user ID", "language selection", etc.

Why can't we just say "it's global" rather than doing all sorts of plumbing to pipe these details around the code base? I know we have stuff like contexts, but it feels a strange workaround, like someone saying "I'm on a diet, no sugar... but put 12 teaspoons of honey in my tea."

I know that the standard line is that it's difficult to test globals, but maybe developing a better test mechanism is a more tractable problem than having to add extra infrastructure to reinvent globals.

Post reply on HN