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

181–190 of 335 posts

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

#181

Post by veeralpatel979 »

nubb wrote: post #3

I’ve been learning React and have been avoiding Redux out of fear of complexity. However, as my app grows more complex, the need for a global state manager becomes more apparent. Time to start learning Redux today :)

Hey - author here.

Try Redux; acemarke has been evangelizing Redux Toolkit [1] recently and it looks great for a beginner not familiar to the Redux ecosystem.

But also - if Redux just isn't clicking for you, or if it is but you feel like writing it is unnatural - know that you're not alone.

Learn MobX, learn how to manage state with context and hooks [2], learn Apollo Client.

Yes it's a lot of up-front work, but you really do need to find a state management approach that works for you if you want to write non-trivial apps, in my opinion.

[1] https://redux-toolkit.js.org/ [2] https://kentcdodds.com/blog/application-state-management-wit...

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

#182

Post by radlad »

shadowgovt wrote: post #145
lhorie wrote: post #128

Earlier quoted context omitted.

I think what GP was getting at is that there's a healthy amount of "if all you have is a hammer" mentality going on w/ React/Redux. The tragedy of commons here is that you _could_ conceivably just slap a class at the root of your React tree to implement dark mode, but if one is using something like styled-components, there's a good chance that the library will get in the way of the style cascading semantics that come…

I don't see why using libraries for complicated interactions atop React is a bad thing.

I'm not sure it's a bad thing - but using a library for DOM manipulation on top of it diminishes the argument that React's advantage is to make DOM manipulation easy.

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

#183

Post by mr_toad »

untog wrote: post #72
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…

To me there’s nothing wrong with React, but everything wrong with people using it in inappropriate contexts. For instance, I’ve seen a growing trend of people creating a whole DOM using React JSX so that they can use React’s server side rendering pipeline. tag all the way down. But the actual reactive components make up about 30% of the page. So you’re wasting download and JS processing time (a serious concern on low…

I don’t understand why you would serve up the React library if you’ve already rendered on the server. I use React server side and then serve the static HTML.

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

#184

Post by radlad »

the_gastropod wrote: post #148
nepeckman wrote: post #85

Earlier quoted context omitted.

I see this sentiment on hacker news a lot, and I honestly dont get it. A list of functionality I've implemented that requires (or is made easier by) JavaScript: Client side validation, error messages, autocomplete, dynamically picking/removing/auto filling fields based on user input, forms that need to know user answers to previous forms, smart tables, update of data pushed from server, sharing markup/functionality b…

> Client side validation The server still needs to validate, no? I've never seen a form that really benefitted from client-side validation. As long as required fields are clearly marked, I don't really understand the value here. > error messages Hmm? What about them needs React? > update of data pushed from server You can poll very cheaply. And even Websockets are pretty simple. Check out Phoenix LiveView or Rails Ac…

> I've never seen a form that really benefitted from client-side validation. As long as required fields are clearly marked, I don't really understand the value here.

Required fields are typically not the only type of validation required by a form. I think a designer would see the value of client-side validation more easily than a developer. It's not to ensure correctness - it's to give the user quick and actionable feedback.

> You can poll very cheaply. And even Websockets are pretty simple. Check out Phoenix LiveView or Rails Action Cable for decent examples of trivial solutions to this.

React isn't helping you poll - it's helping you structure your application in a way that ensures all components receive the updated data.

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

#185

Post by hi41 »

I am just a regular C/C++ developer. When I read OP's article, I was dismayed by the number of tools or frameworks he refers to. I wish to become a web/app developer. How do I climb such a steep curve? Can someone please suggest a good online course.

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

#186

Post by adamkl »

UberMouse wrote: post #121
adamkl wrote: post #91

Earlier quoted context omitted.

Just xState. Each machine is responsible it’s own piece of the global state pie by using its internal `context`. This allows a similar approach to redux’s actions and reducers (or events and `assign` for xState), but each machine can focus on its area of responsibility and enforce its behaviour through defined state transitions. This approach also makes it easy to coordinate between multiple services (e.g. having the…

> e.g. having the “NavigationService” change which links should be available by listening to a state change on the “UserSession” service as a user becomes authenticated. Could you expand on how you're achieving this? I'm creating a new project using xState at work and this is one of the things I've been trying to come up with a solution too. My biggest problem is the pattern I've set up for routing on top of xState (…

We keep things very simple. Maybe that will have to change as the code base grows, but for now it works and it easy to grok.

On start of the application we create singletons of our state machine backed services, and manage the dependencies between them manually. That is, we create an instance of the UserSessionService and then pass it into a "constructor" for the NavService. That constructing function creates the NavService and then wires them together by subscribing the NavService to listen to the state transitions of the UserSessionService.

I suppose if the code base grows and you have dozens of services to keep track of, it will get pretty unwieldy, but that is no different than using a fancy IOC container in Java/.Net. We plan on keeping things simple, while still braking apart the single store you'd have with Redux.

I hacked together a simple gist to show the basics of how we wire things together (without getting into the specifics of how the internals of the state machines work). [1]

[1] https://gist.github.com/adamkl/656008691d42220eddf8bfe147753...

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

#187

Post by adamkl »

fold_left wrote: post #149
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 love the sound of this, do you have a link to any examples?

https://news.ycombinator.com/item?id=22294087

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

#188

Post by veeralpatel979 »

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…

Hey - author here. React is just simpler for me to reason about. A app has many pages, a page has many components. I can write components; I can write Redux/MobX code; I can pass data between components. Things work.

But absolutely, my speed of development when using React is lower than when I'm using server-generated HTML in a Rails app.

On the other hand, I can do things with React I can't do with server-generated HTML.

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

#189

Post by tobyhinloopen »

hi41 wrote: post #185

I am just a regular C/C++ developer. When I read OP's article, I was dismayed by the number of tools or frameworks he refers to. I wish to become a web/app developer. How do I climb such a steep curve? Can someone please suggest a good online course.

Just start with a plain React application, follow the react tutorials. Build something simple.

Other tools and frameworks are all optional. I’m a frontend dev and I never used many of the tools he mentioned.

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

#190

Post by deanclatworthy »

Didn’t catch any mention of hooks in this article. My advice is only use redux when two components need access to the same information within a few seconds of whatever you are doing.

Otherwise I’d put all data fetching into hooks which can give any component which uses it access to all kinds of information and the ability to conditionally render.

I have found this pattern to be cleaner than using component lifecycle methods. An example can be seen here:

https://github.com/deanc/buyxiny.com/blob/master/site/src/co...

Post reply on HN