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

41–50 of 335 posts

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

#41

Post by the_gastropod »

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 know what theme is on, so they can render the UI in the right color.

Back in my day.... you'd slap a class on the tag, and you'd have all you'd need for your CSS to style the rest of the page accordingly. How is using Redux an improvement here?

None of the examples of "complex" front-ends would be at all difficult in an old-school "just re-render the page" setup using something like pjax or turbolinks. And in my experience (seeing web pages with > 1MB js files) it'd be faster/more responsive for the end-user too.

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

#42

Post by timw4mail »

breytex wrote: post #26
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…

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.

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

#43

Post by tempsy »

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…

any mildly interesting SPA will need to keep track of state somehow. passing state between react components is more complicated than using redux.

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

#44

Post by miglmj »

jamil7 wrote: post #34
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…

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.

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

#45

Post by mfrye0 »

brlewis wrote: post #23

Point 2 in this article says a global store is the solution to its example problem. If there are any details of the example problem that make a global store the best solution, those details are not given. Generally you store a component's state in the component, and store shared state in a common ancestor of the components that share it.

Yeah, he didn't do the best job of explaining why in that example.

Using a global store makes sense when your todo list evolves and the component storing the data is no longer mounted / exists. Examples could be:

- Full page individual todo edit - Separate component / page that uses the same data - Some background logic that does X based on the todo data

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

#46

Post by nightski »

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…

I never find myself "burned" by locally stored state because it's trivial to move state up the tree and pass it down as props. But boy does it simplify an application a lot using locally stored state where it makes sense.

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

#47

Post by jfengel »

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 React to help manage global state; again, it's compensating for just how bad Javascript is.)

Bonus: React encourages the use of JSX, a language that makes a lot of behavior look as if you were writing it directly in HTML. You don't need React to use JSX, and you don't need JSX to use React, but they do dovetail nicely.

You can write in plain JS/jquery if you want. Plenty of people do. React is a framework to make that a bit easier; that's all.

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

#48

Post by interlocutor »

acemarke wrote: post #37
wolco wrote: post #32

Earlier quoted context omitted.

Please explain the flux pattern?

See the docs for the original Flux Architecture: https://facebook.github.io/flux/docs/in-depth-overview Redux was originally designed as a Flux implementation: https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

From that Facebook article: Flux eschews MVC in favor of a unidirectional data flow.

This is so incorrect. MVC doesn't imply two-way data binding. The whole Flux architecture was based on a misunderstanding of MVC, and is therefore questionable.

Most UI frameworks, including iOS, ASP.NET Core, JSP and JSF (Java based frameworks), Ruby on Rails, and Django (Python) are all based on MVC.

Why is it that MVC works for all these other frameworks, but doesn't for React? The answer is that MVC does in fact work for React. React itself originally used the tagline "React is the V in MVC". Flux/Redux introduce needless complexity and unnecessary boilerplate. There are MVC libs that make React much easier to use.

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

#49

Post by acemarke »

karatestomp wrote: post #40
acemarke wrote: post #35

Earlier quoted context omitted.

Understanding the original context and intent of a tool is important. Back in 2017, I wrote a post that covered the overall intent behind Redux's design [0], as I was already seeing that folks didn't know the background. That lack of understanding behind Redux's history has become more apparent over time. The terminology exists because Redux was originally designed as "just" another implementation of the Flux Archite…

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

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

#50

Post by Supermancho »

rhacker wrote: post #24

I think the largest myth that exists in the react world is the need to have a global state for everything. I've seen too many failures when teams go from displaying "this one thing" to suddenly have the requirements to display two or more of that at the same time. Redux global state for the user that is logged in? that's OK, but do you really need Redux for that? Our team uses hooks and context for everything, and a…

> I think the largest myth that exists in the react world is the need to have a global state for everything.

Client state management is all global no matter the strategy. ie Component level stores are effectively namespacing a global space with more cruft.

When you get into sets of components, the convenient store gets ugly/brittle no matter how you do it, so might as well keep it in a single store.

Post reply on HN