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

Things I wish I knew about state management when I started writing React apps

medium.com

Post reply on HN
Print view View original

51–60 of 335 posts

Re: Things I wish I knew about state management when I started writing React apps

#51

Post by simonsarris »

the_gastropod wrote: post #41

I'm one of those "old dogs" who don't quite get the advantage of using React in the majority of the cases it's used. This article didn't really help... > What makes these frontends complex? State management. The frontend “knows” a lot of things, and these things interact with each other in non-trivial ways [...] Example: dark mode support. For example, say your app has a dark mode. All your rendered components must k…

I've always preferred hand-crafted websites with readable view-source over frameworks, but I finally switched to react so I could keep my site's background animations persistent over pages. It' somewhat unfortunate that its still not possible without some JS (in this case, a framework that's swapping out portions of the page).

Re: Things I wish I knew about state management when I started writing React apps

#52

Post by cuddlecake »

Waterluvian wrote: post #28

I'm starting to lean towards holding ALL app state in a single store rather than having component local state because every so often I get burned by not seeing the future. Example: okay I have a bunch of tabs that show different views. The state for which tab is selected can live with the tab container. Months later I find that I need other parts of the app to be able to switch to a different tab when user actions ha…

At some point, you might even want to only have one drop-down open across an entire site, so there goes your local drop-down state :P

Re: Things I wish I knew about state management when I started writing React apps

#53

Post by karatestomp »

acemarke wrote: post #49
karatestomp wrote: post #40

Earlier quoted context omitted.

Yeah, I know the history of the terms, I just find them so entirely unhelpful for (harmful to, in fact) understanding Redux, no matter what reason they're there, that providing a translation is pretty much the first thing I do when introducing someone to it. Figuring out what the terms actually meant was the moment I went from "what... what is this thing doing?" to "oh it's a couple very simple things I already under…

As I've already said in this thread, we're currently working on a docs rewrite to try to update things for today's target audience: https://github.com/reduxjs/redux/issues/3592 . As part of that, we'll be adding better explanations of terminology. (and by "we" I mostly mean "me", since I'm not getting a lot of help from the community with this task atm.)

Thanks for your work on it. Seriously. I've enjoyed my time with Redux, more or less, and was in no way trying to shit on it with my comments—I hope it didn't come across that way.

Re: Things I wish I knew about state management when I started writing React apps

#54

Post by acemarke »

trufas wrote: post #29
tempsy wrote: post #10

Earlier quoted context omitted.

I never understood why redux was considered "hard" - it basically keeps track of a plain javascript object that you can read/write across a react app

I think that plays along the lines of Rich Hickey's simple vs easy idea. Sure, a beginner will understand your explanation, but they might still run into trouble doing common UI things using it. Redux also has a reputation for being annoying to write because people cargo cult it into any project regardless of scope and because utilities like the excellent `redux-toolkit` weren't and still aren't as widespread as they…

> because utilities like the excellent `redux-toolkit` weren't and still aren't as widespread as they should be.

hey, I'm trying to broadcast it as much as I can :)

fwiw, the adoption curve is definitely going up:

https://npm-stat.com/charts.html?package=%40reduxjs%2Ftoolki...

And the growth of the RTK package is especially impressive given that we renamed it from "Redux Starter Kit" to "Redux Toolkit" _after_ we'd released RSK 1.0.

We'll emphasize RTK even more as part of the ongoing Redux core docs rewrite. My goal is that it ultimately becomes the default way to write Redux logic, in much the way that the Apollo folks tell you to use `apollo-boost` and React devs default to use Create-React-App.

Re: Things I wish I knew about state management when I started writing React apps

#55

Post by ehutch79 »

qwerty456127 wrote: post #21

> Think about the most complex frontends you’ve used. Frontends that made you wonder — “how did they create this”? What makes these frontends complex? State management. The frontend “knows” a lot of things, and these things interact with each other in non-trivial ways. So in my view, state management is the core problem when developing a UI. To build a non-trivial React application, you need to consider state managem…

If you're using js state management for dark mode, something has gone horribly wrong.

Re: Things I wish I knew about state management when I started writing React apps

#56

Post by brlewis »

the_gastropod wrote: post #41

I'm one of those "old dogs" who don't quite get the advantage of using React in the majority of the cases it's used. This article didn't really help... > What makes these frontends complex? State management. The frontend “knows” a lot of things, and these things interact with each other in non-trivial ways [...] Example: dark mode support. For example, say your app has a dark mode. All your rendered components must k…

I get the advantage of using React for single-page web apps, but I'm totally with you on the dark mode example.

The modern way to do dark mode is to assume that people who want it won't be using IE or Edge, and just do a CSS media query. https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...

Re: Things I wish I knew about state management when I started writing React apps

#57

Post by vga805 »

miglmj wrote: post #44
jamil7 wrote: post #34

Earlier quoted context omitted.

This is the way Elm works and I believe some people used or advocated for using Redux in this way early on. It never really caught on in React apps in my experience but it makes some interesting debugging methods easy to implement.

This is also how it works in Clojurescript (through Reagent/Re-frame). I don't have too much JS react experience, but I often read this kind of article and marvel at how huge the mental load is working on react projects in native JS.

You use a global db atom in re-frame for global state, but there's nothing stopping you from using a reagent atom local to a component, is there?

I never thought of the existence of the global db as the thing that ALL state should go in., or is that a community best practice?

Edit: after digging through the re-frame docs themselves, you can see here that local reagent atoms are used for local state even with the global app db: https://github.com/day8/re-frame/blob/69a3fcd411369fff65404e...

Re: Things I wish I knew about state management when I started writing React apps

#58

Post by aphextron »

adamkl wrote: post #31

To manage state in our React application, we have a "service layer", just like you’d see in a server side application, only these are based on state machines (reactive services based on RxJS observables works as well). We also created associated custom hooks that allow developers to easily "inject" a service into their React component (we use React's Context API for our "DI container"). From there developers can read…

Are you guys using xState entirely as your data store, or using something else in conjunction like MobX or Redux?

Re: Things I wish I knew about state management when I started writing React apps

#59

Post by Eire_Banshee »

timw4mail wrote: post #42
breytex wrote: post #26

Earlier quoted context omitted.

You got that wrong. Modern JavaScript / SPAs make it possible to implement something like Outlook right within your browser. No (big) download, no clicking through an installation wizard, no fragmentation of versions for a tool, which forces you to be online anyway. I don't get all the hate towards SPAs and JavaScript Frameworks here on HN. Everyone is basically complaining about complexity for applications, which ar…

Nobody asked for stupid native-level functionality nonsense in the browser. It takes too much Javascript, which is not efficient to parse or run, and is usually wasted on "looking/feeling fancy", not actual functionality.

Looking and feeling fancy is often what sells though... that is ultimately more important.

Re: Things I wish I knew about state management when I started writing React apps

#60

Post by the_gastropod »

jfengel wrote: post #47
the_gastropod wrote: post #41

I'm one of those "old dogs" who don't quite get the advantage of using React in the majority of the cases it's used. This article didn't really help... > What makes these frontends complex? State management. The frontend “knows” a lot of things, and these things interact with each other in non-trivial ways [...] Example: dark mode support. For example, say your app has a dark mode. All your rendered components must k…

React and Redux are for apps. If you can do it with HTML/CSS, you absolutely should. React/Redux are a replacement for what people used to do with jquery or plain JS. They're not for display; they're for complex interaction of the kind that used to require a native user interface (Java Swing, Gtk, Win32, etc). Javascript is a mess, and the DOM is a mess; React makes that slightly less awful. (Redux is an extension to…

I actually write a good bit of React professionally. I'm familiar. I just have yet to see a very compelling case. And the excuse is almost always this nebulous "rich/complex interaction". And.... I just rarely see any good examples of this. The huge majority of apps (web or otherwise) are not video games. They're forms that submit stuff to a server and get a response. There's sometimes a dropdown here or there.... and that's it.
Post reply on HN