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

121–130 of 335 posts

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

#121

Post by UberMouse »

adamkl wrote: post #91
aphextron wrote: post #58

Earlier quoted context omitted.

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

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 (It's an electron app so no URL management required which makes that easy) requires you to create the state machine yourself, so it can't for example be used as an actor in part of a larger system.

It sounds like your NavigationService and UserSession service might be similarly separated so I'm curious how they're communicating?

Something that occurred to me last night is that I can probably make a coordinator of some sort somewhere in the tree which forwards actions from state machine to another as required.

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

#122

Post by bernawil »

pests wrote: post #120
bernawil wrote: post #102

Earlier quoted context omitted.

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…

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.

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

#123

Post by beefalo »

spion wrote: post #79
spion wrote: post #68

Earlier quoted context omitted.

One of the reasons is the difficulty of writing reusable interactive components with server-side rendering such as maps, rich text editors, autocompletes, hover previews, menus. The components work with data. Let's say you need an auto-complete component - 500ms after the user starts typing it will query the server and get some data back. You can describe the returned data in partially rendered HTML too but the attri…

For reference, here is a "simple" app - a parametric EQ designer that supports doing pink noise measurements of speakers (or headphones if you have the right equipment) with FFT in the browser: https://eq.spion.dev/ - works as an entirely static website :) Typically what people say is "oh most websites won't need THAT" but the appetite for interactivity only grows with most companies, so you could easily end up in a…

What definition of static website are you using here? If I turn of JavaScript all i get is "You need to enable JavaScript to run this app."

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

#124

Post by hashamali »

pier25 wrote: post #108

> You can make API calls in your actions just like you normally would Jesus don't do this. Mobx, Vuex, Redux, etc, are about managing application state not about managing application logic. I started making SPAs in 2015 and I also used actions for everything (API calls, auth, etc). It was fine for small projects but then I got to work on a medium sized project and those actions became huge and controlled everything i…

I think this is generally a side effect of people considering actions to be a replacement for the Controller part of MVC. Meaning any sort of logic (including legitimate state manipulation) is jammed into actions.

Personally, I don't see that as a huge problem. Better in an action than sprinkled into components. As someone else mentioned, redux-thunk makes this even easier (and one could argue, promotes this).

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

#125

Post by alfonmga »

I'm in the process of building a B2B multi-tenant SaaS application and one of the best decisions I made so far was to use Easy Peasy [0] to handle the state of my React application logic. It has a very intuitive and powerful API. I would recommend everyone to take it a look as it is not very known.

[0] https://github.com/ctrlplusb/easy-peasy

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

#126

Post by spookthesunset »

crtlaltdel wrote: post #111
spookthesunset wrote: post #99

Earlier quoted context omitted.

> I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework Ah but if you actually looked at what you built, I am 100% sure you folks built your own framework instead. A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation. You will never be able to hire talent that…

i've seen a shop start as a "no-framework" effort and it did indeed become an "internal framework" project. imo it was a strange choice, given how much effort had to go into maintaining and bugfixing the internal framework...mostly issues that would have been flushed out in something with wider support. before being involved in mostly "modern saas", i was heavy in electrical/electronics mfg and there was always a ten…

> i seriously know a person who was like "hrm, lets build our own pick-and-place for the smt line..."

I mean, how hard could building our own pick & place be, right? Once you strip out all the bloat the vendors add to make a sale, it is nothing you couldn't do with a couple servos and a $5 Arduino, right?

I think the "build everything ourselves" attitude comes from a not at all understanding opportunity costs and comparative advantage. Plus in the software industry, tons of developers I've encountered are super paranoid about "vendor lockin" without realizing that once they roll their own library/framework/pick-and-place-machine they have effectively locked their employer into a vendor as well. Only instead of a third party vendor with all the benefits that may come with it, they've "purchased" a product from a really shitty vendor--themselves!

It is never a choice between:

"Platform or no platform"

"Framework or no framework"

"Vendor lock-in or no vendor lock-in"

You will always be on a platform. You will always be using a framework and you'll always be locked into a vendor. The trick is to make sure you don't lock yourself into a shitty vendor who makes a shitty platform or framework.

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

#127

Post by soneca »

acemarke wrote: post #97
soneca wrote: post #82

Ok, only tangentially related. I would appreciate anyone more knowledgeable than me in React chipping in: Why Redux is the norm for React state management? Follow-up specific question: In which cases is it better than react-easy-state[0]? I am using react-easy-state on my company and on my side-project web apps. For me at least, it seems to add much less cognitive overhead than Redux. It is simpler to understand, sim…

I'm a Redux maintainer. There's a bunch of reasons why Redux took off: - In 2014, a year after introducing React, Facebook announced the "Flux Architecture" concept [0]. Since it was mostly just a pattern and not a library, over the next year the community created dozens of competing Flux-style libraries, which I've referred to as "The Flux Wars" [1]. - Redux came out in the middle of 2015. Its design took inspiratio…

Thanks! That was an incredible comment, thanks for taking the time to do it.

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

#128

Post by lhorie »

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 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 for free w/ the browser. And ultimately, the end-user is the one paying the price for all the extra code needed to make a "complexity-friendly" implementation of dark mode work.

Another observation that I've been finding interesting about "modern frontend development" is that despite all the arguments about how React makes DOM manipulation easier, people still prefer to defer to libraries to do any non-trivial amount of DOM manipulation rather than actually use pure React to do it. This is exactly the same modus operandi as when jQuery was "modern frontend development" ("it makes it easier to work w/ DOM", plus a ton of opaque jquery-* libs)

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

#129

Post by nohuhu »

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

Check out Statium: https://github.com/riptano/statium, and the RealWorld example that I threw together in a couple of evenings: https://github.com/nohuhu/react-statium-realworld-example-ap.... The basic idea is to have state kept in a separate component that deals just with state, a ViewModel. Internally it works just the same as usual React components: by calling `this.setState()`; externally it exposes API for getting key values and setter functions, same as hooks do.

It's really easy to work with, and the concept of hierarchical state store is something that I haven't seen in any other library. If there was I probably wouldn't end up writing Statium in the first place. :)

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

#130

Post by frenchyatwork »

switch007 wrote: post #118
some-guy wrote: post #61

Earlier quoted context omitted.

For individuals making small sites, it's absolutely overkill. For my job, with hundreds of developers working on a giant SPA blob with constant feature creep, frameworks like React are a necessary evil to maintain the insanity.

React is just a library though. Surely there is much more to your story than React alone?

Sure, React is just a library, but I don't think I've ever seen it used as just a library.
Post reply on HN