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

261–270 of 310 posts

Re: The new wave of React state management

#261

Post by jitl »

wizofaus wrote: post #260
emptysea wrote: post #236

Earlier quoted context omitted.

I find the big difference for me when building an API vs working on a UI is the testing. I think backend APIs tend to be much easier to test than UIs. For the backend, it's mostly Request in Response out, check they look good and the side effects (database, caches, queues, etc.) are performed etc. For the UI you have a lot of async stuff going on and writing non-flakey tests is tricky and verbose with the current too…

Absolutely - realistically you never can automate UI tests fully, as there's no way of describing all the things humans "expect" to experience while using a UI. Even when you can, the effort involved in creating and maintaining the tests and confirming that the failures are genuine often doesn't justify the benefits.

I think this suggests that UI is more complex than API.

Re: The new wave of React state management

#262

Post by KronisLV »

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 like React's easy approach to making components a bit more, even more than Vue 3 with Composition API. That said, Pinia (https://pinia.vuejs.org/) does indeed seem like an excellent approach to state management!

My only problem is that my IDE of choice (WebStorm) is incapable of providing any sort of autocomplete for it, with JavaScript. For example, consider the following store, as an example from their documentation:

  export const useCounterStore = defineStore('counter', {
    state: () => {
      return { count: 0 }
    },
  });
Really simple to define it and then change it with $patch, right? Well, when I try to access the field which is included in the default values, my IDE won't show me the available fields when used in some component:

  const counterStore = useCounterStore();
  const isSomethingExceeded = counterStore.count; // .count does not get offered as an autocomplete option
That is kind of annoying, when you have a whole bunch of different fields in there, even if you can predict which kinds.

Well, there's also the thing where WebStorm refuses to insert tag or even add imports inside of it if it's present in the header of the page, but instead I get a redundant tag at the bottom with the old Vue syntax for defining components, which I then have to clean up manually.

Re: The new wave of React state management

#263

Post by aliswe »

theteapot wrote: post #253
42e6e8c8-f7b8-4 wrote: post #179

Earlier quoted context omitted.

I believe the worst part is redux. React is mostly reasonable. Redux is massive boilerplate.

> I believe the worst part is redux .. And hooks. Sorry but React started to go crazy when hooks IMHO.

To me, this is where React started to make sense ...

Re: The new wave of React state management

#264

Post by wizofaus »

jitl wrote: post #261
wizofaus wrote: post #260

Earlier quoted context omitted.

Absolutely - realistically you never can automate UI tests fully, as there's no way of describing all the things humans "expect" to experience while using a UI. Even when you can, the effort involved in creating and maintaining the tests and confirming that the failures are genuine often doesn't justify the benefits.

I think this suggests that UI is more complex than API.

Then you've never written APIs that have to do super complex calculations or process huge amounts of data efficiently and reliably. By far the most complex code I've had to deal with has been "back-end engine" type code, even if it was technically part of a desktop application (but wasn't dealing with user interactions).

Re: The new wave of React state management

#265

Post by lifeplusplus »

theteapot wrote: post #253
42e6e8c8-f7b8-4 wrote: post #179

Earlier quoted context omitted.

I believe the worst part is redux. React is mostly reasonable. Redux is massive boilerplate.

> I believe the worst part is redux .. And hooks. Sorry but React started to go crazy when hooks IMHO.

I had a project where state was coming through redux, from parents via props, context somewhere from parent elements, xhr fetch/graphql, local storage... Debugging was hell. I've always hated hooks, they replaced easy and clear lifecycle functions and rely on magic to work, literally don't function like regular js functions but look like regular functions

Re: The new wave of React state management

#267

Post by KronisLV »

lifeplusplus wrote: post #265
theteapot wrote: post #253

Earlier quoted context omitted.

> I believe the worst part is redux .. And hooks. Sorry but React started to go crazy when hooks IMHO.

I had a project where state was coming through redux, from parents via props, context somewhere from parent elements, xhr fetch/graphql, local storage... Debugging was hell. I've always hated hooks, they replaced easy and clear lifecycle functions and rely on magic to work, literally don't function like regular js functions but look like regular functions

> Debugging was hell. I've always hated hooks, they replaced easy and clear lifecycle functions and rely on magic to work, literally don't function like regular js functions but look like regular functions

You know, with how hooks work in Vue, things seem be easier to understand and get started with.

Though at least with React I've had plenty of projects end up with render loops that are hard to debug because of how everything is written. So much so, that I wrote a blog post about it a while back "Modern React is broken": https://blog.kronis.dev/everything%20is%20broken/modern-reac...

Personally I wish that we could already have some tooling that'd tell you something along the lines of:

  Render loop detected! The following chain of calls was responsible for it: A -> B -> C -> A -> B -> ...
  Please check the useEffect hook on line X, which has the following items in its dependency array which changed: [Y, Z]

Re: The new wave of React state management

#268

Post by KronisLV »

ishitatsuyuki wrote: post #227
wokwokwok wrote: post #222

Earlier quoted context omitted.

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 o…

> 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.

I actually recently looked into most of the frameworks out there and their migration efforts.

So far, I only found three viable options for Vue 3:

  - PrimeVue https://www.primefaces.org/primevue/
  - Quasar https://quasar.dev/
  - Element Plus https://element-plus.org/en-US/
We went with PrimeVue and while using PrimeFaces was an incredible pain with Java, the Vue version seems a bit better. Then again, it's kind of odd that libraries as popular as Bootstrap don't have complete bindings in the form of Vue 3 components.

Re: The new wave of React state management

#269

Post by nyanpasu64 »

valand wrote: post #259
nyanpasu64 wrote: post #226

Earlier quoted context omitted.

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…

I haven't worked with Qt so I don't know how the API looks, But on a complex app, to see "dirty bitflags", "intermediate values", "redrew the UI in the middle of mutating document state", I feel what you feel, and I want to share what helps me and my team overcome this kind of complexity. This happened a few years ago to my team. We alleviated this with several solutions. The most effective solutions is to 1.) separa…

Sorry, I don't understand what you're getting at. When timers or user actions are triggered, what code runs, where is the state it modifies located (next to the specific timer/action, within a module or dialog's object, or globally), how does the function determine which parts of the UI to reload from state, and when does it reload the UI? (Is this explained in the video or not? I haven't watched it yet.)

Re: The new wave of React state management

#270

Post by 5350-uiop-1130 »

I remember there being about 5 layers of abstraction to using Redux. Every time you change something have to update 5 or 6 files. It really gave me Angular 1 vibes.

One thing I learnt from all these JS libraries and Node is that nothing is for free. If it seems too easy, then something gonna bite you in the ass down the line.

Post reply on HN