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

151–160 of 335 posts

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

#151

Post by inviromentalist »

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…

Literally to avoid joining the apple ecosystem.

If I can make an app that services 100% of users and merely borrow a friend's Apple product to hit "compile", I will.

Heck it's enabled me, because prior, I had only provided services to Android and web.

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

#152

Post by the_gastropod »

bernawil wrote: post #102
the_gastropod wrote: post #60

Earlier quoted context omitted.

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

They're forms that submit stuff to a server and get a response What kind of response? Asuming no React, a. json b. SSR-html? If, a. Now you've got to process that response, handle errors and finally render into html. You'll be either imperatively replacing DOM nodes, interpolating string templates or both. Probably re-binding event handlers after that. b. You'll be merging your server-rendered html to your current vi…

pjax is about a decade old at this point, dirt simple, and easily handles re-binding event handlers. Check it out: https://github.com/defunkt/jquery-pjax

Turbolinks is a more contemporary library that does much the same.

It doesn't need to be complicated.

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

#153

Post by mr_toad »

the_gastropod wrote: post #60
jfengel wrote: post #47

Earlier quoted context omitted.

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

> They're forms that submit stuff to a server and get a response.

React is overkill for something that simple. You don’t even need JavaScript for simple forms.

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

#154

Post by the_gastropod »

bernawil wrote: post #122
pests wrote: post #120

Earlier quoted context omitted.

You forget the most basic response. A full HTML file with a corresponding reload. None of what you said applies. I'm a big react fan and advocate too but sometimes I think we forget about the basics.

First time I hear XMLHttpRequest was a mistake. No one is going to sit through a full-page reload on every form validation. Even intermediate solutions that merged (hacked) client-server state failed too. APIs are just better.

The irony is you're posting on HN, which does exactly what you suggest no one will tolerate. How slow is this form submission for you? ;-)

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

#155

Post by ChrisCinelli »

ChrisCinelli wrote: post #147

For state management I would start with reading "Thinking in React": https://reactjs.org/docs/thinking-in-react.html Step 3 is key. Step 4 is also important. Then try to simplify the app as much as you can. A system has always 2 kind of complexity: the intrinsic complexity and incidental complexity. "Smart engineers" like to show off their intelligence. That usually end up making their life harder by adding a lot of…

When a system has high intrinsic complexity good architecture design is one way to mitigate the problem.

The best way that I found so far are the principles of Object Oriented Analysis and OO Design ( https://en.m.wikipedia.org/wiki/Object-oriented_analysis_and... ) to break down the system in autonomous subsystems that make sense.

Generally the best philosophy is keeping things as simple as possible and refactor as new complexity is necessary.

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

#156

Post by ellius »

onesmalldrop wrote: post #137
ellius wrote: post #75

Earlier quoted context omitted.

Debatable but I get your point. The thing is that Flux is a pattern, and you often want to test the full pattern to get a meaningful "unit" of behavior/logic. There can be meaningful logic in the individual pieces, but frequently they only make sense as a whole.

It's not debatable... Unit tests are for testing individual components of your application (web or otherwise) e2e or integration tests are for testing your application component/lib/api/whatever boundaries

Sure, but what do you count as a "component"? It varies by language, framework, platform, and pattern.

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

#157

Post by nohuhu »

onesmalldrop wrote: post #137
ellius wrote: post #75

Earlier quoted context omitted.

Debatable but I get your point. The thing is that Flux is a pattern, and you often want to test the full pattern to get a meaningful "unit" of behavior/logic. There can be meaningful logic in the individual pieces, but frequently they only make sense as a whole.

It's not debatable... Unit tests are for testing individual components of your application (web or otherwise) e2e or integration tests are for testing your application component/lib/api/whatever boundaries

How do you test individual components in isolation if they depend on the global state store?

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

#158

Post by ChrisCinelli »

ChrisCinelli wrote: post #147

For state management I would start with reading "Thinking in React": https://reactjs.org/docs/thinking-in-react.html Step 3 is key. Step 4 is also important. Then try to simplify the app as much as you can. A system has always 2 kind of complexity: the intrinsic complexity and incidental complexity. "Smart engineers" like to show off their intelligence. That usually end up making their life harder by adding a lot of…

I do not like Redux a lot. It leads to a lot of boilerplate code and a lot of extra files. It also exposes transparently the state that lead by default to a coupling between the "internal" data rappresentation and the rest of the UI components making refactoring a nightmare.

Mobx at least leads to a more concise codebase.

GraphQL and Relay/Apollo/etc help a lot to reduce the business logic in the front and code to written in general.

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

#159

Post by adamkl »

onesmalldrop wrote: post #132
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…

I wouldn't call it the "best part." It sounds like you took the service focused angular patterns you were using before and shoehorned them into a React application. How comfortable would you be allowing an outside dev to hack on your codebase without a _long_ conversation beforehand explaining the idiosyncrasies?

From my view point, we “shoe-horned” a React UI into a well-established pattern for building an application.

I guess it depends on the vintage of the developer. I would argue that Redux is an idiosyncratic technique for state management, and by breaking it apart into separate services, you get better separation of concerns.

I should point out though, that our “service layer” follows the same event-driven flow that you would see with Redux, but by breaking it up into state machines we can be more explicit about the states of our application.

“Service layer” doesn’t have to be a dirty word. Redux is a stateful, reactive service, and so are the xState machines we are using. Logically speaking, I don’t see much of a difference.

As for the _long_ conversation you mention, in my experience, it’s actually been a pretty short conversation followed by gratitude at not having to use Redux. I really don’t meant that as a slight towards Redux, which is a very elegant solution, but seriously, the people I’ve introduced to xState just like it better.

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

#160

Post by veeralpatel979 »

brlewis wrote: post #17

Point 1 in this article is totally misguided. "State management is how you mitigate prop drilling" implies that when prop drilling is not a problem (i.e. most of the time), that you don't need to think about state management. Even if you're prop drilling, you need to make sure data is not stored/updated in multiple places in your app in order to keep the UI consistent. The one redeeming part of that section of this a…

Hey - author here. I did not mean to imply that state management is only useful to mitigate the prop drilling problem. In fact, in #2, I give another example where state management is useful.
Post reply on HN