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

271–280 of 335 posts

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

#271

Post by imiric »

z3t4 wrote: post #191
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…

I just use vanilla JS. For transport I use JSON over Websockets (with fallback to long-polling if the user is behind a proxy that doesn't support Websockets). I format the messages like id+command+json-payload. If the message contains an id, it calls the callback function given by the API request. If no id is given, the event listeners for "command" are called. In a higher level there are more events that can be list…

That sounds like a great framework. Let us know when you release it. :)

The points made elsewhere in this thread still stand: a bespoke framework might be conceptually simpler and much easier for a solo developer, but for larger apps that require a team of developers using a popular framework would be much more productive overall, as everyone is or should be on the same page with how features are implemented. This often results in poor UX where specialized knowledge about the framework is needed to improve performance and scale, which you as the author of yours know by heart and find it much easier to achieve similar or better results.

I'd say neither approach is inherently bad. Use whatever delivers the best UX for the project at hand, but know that you'll be paying a price when that approach reaches its limits.

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

#272

Post by Tehdasi »

cactus2093 wrote: post #233
PaulDavisThe1st wrote: post #224

So let me just check that I understand this correctly. A whole bunch of problems that were "solved" (or at least, had fairly good solutions) in the context of desktop GUI toolkits have resurfaced in the context of application development confined to the web browser. Almost none of the previous "solutions" are usable, because of the specifics of the theoretically portable "browser platform" for which all this developm…

Genuinely curious, as someone who wasn't building desktop apps 20 years ago, what are the toolkits you're referring to? When I google "cross-platform desktop frameworks", the entire first page of results are all about the modern toolkits like Electron, Photon, ReactNativeEverywhere, etc. So it seems like your complaint is many years too late at this point. Maybe there were solutions to this 20 years ago, but if I'm s…

The problem is that in the days before web UIs is also a different landscape in terms of the computing resources available, and the amount of security required. These were the problems that applications were focusing on solving. Because of this, the tools that developers were using were different, and don't make as much sense nowadays.

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

#273

Post by PaulDavisThe1st »

rendall wrote: post #261
cactus2093 wrote: post #233

Earlier quoted context omitted.

Genuinely curious, as someone who wasn't building desktop apps 20 years ago, what are the toolkits you're referring to? When I google "cross-platform desktop frameworks", the entire first page of results are all about the modern toolkits like Electron, Photon, ReactNativeEverywhere, etc. So it seems like your complaint is many years too late at this point. Maybe there were solutions to this 20 years ago, but if I'm s…

How do these older frameworks (Qt, etc) approach state management?

Well, first of all, the problem in its most basic sense doesn't even really exist for many places where you would use "Qt, etc". You wouldn't be reacting with a remote server or if you are you have a stateful connection with the remote server. That's true whether the "remote server" is just a database server or something more specific.

But going somewhat deeper (and based on reading all the defenses of "React, etc" in the comments thus far), the fundamental difference is that if you were using a desktop GUI toolkit, you would almost certainly assume that there's essentially zero cost (or almost neglible cost) to the communication between the data (model) and the GUI. This is (one of the things) that is so different for web development, where everybody is struggling to optimize away roundtrips back to the data (server), because it actually costs.

Put differently, whatever protocols might be implemented inside a desktop GUI to talk to a not-in-memory data source, the protocols are almost certainly designed for precisely that purpose. Whether its a vendor-supplied connection to an SQL database, an application-specific serialization/deserialization protocol, some IP-based message passing protocol ... whatever, it will all have been designed for the express purpose that it is being used for (more or less).

HTTP? Ahem. Granted, web app development has augmented HTTP in various ways (most dramatically would probably be websockets/webrtc). But fundamentally, the state management issue in a web app originates with the fundamentally stateless communication protocol being used between the app and the data sources/servers it is dependent on.

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

#274

Post by ncallaway »

the_gastropod wrote: post #196
radlad wrote: post #184

Earlier quoted context omitted.

> 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 f…

> it's to give the user quick and actionable feedback. Right.. But I think often times the difference is pretty overblown. Clicking "save" and getting that feedback in ~100ms is not, in my estimation, worth the massive extra overhead of using a front-end framework, duplicating your validation requirements, etc. If you're google or facebook or youtube or are otherwise printing money, go for it. But for the 99% of web…

> Right.. But I think often times the difference is pretty overblown. Clicking "save" and getting that feedback in ~100ms is not

Let's say the form has 5 fields, and I as the user make an error in the first field.

Why do I have to finish filling out the entire form to hit "save", to discover I made an error in the first field? That's not a difference of ~100ms, that's a difference of several seconds (or tens of seconds for a medium-complexity form).

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

#275

Post by PaulDavisThe1st »

rendall wrote: post #261
cactus2093 wrote: post #233

Earlier quoted context omitted.

Genuinely curious, as someone who wasn't building desktop apps 20 years ago, what are the toolkits you're referring to? When I google "cross-platform desktop frameworks", the entire first page of results are all about the modern toolkits like Electron, Photon, ReactNativeEverywhere, etc. So it seems like your complaint is many years too late at this point. Maybe there were solutions to this 20 years ago, but if I'm s…

How do these older frameworks (Qt, etc) approach state management?

I just thought of another critical difference when using "Qt, etc". These toolkits all have at their heart an event loop that looks something like:

    while (!should_quit()) {
          wait_for_user_input_or_other_events();
          process_events(); // may mark some components for redraw
          redraw_anything_that_needs_it();
   }
So if user input or some data source indicates that some on-screen component now needs to be red with a yellow border, the "process events" stage makes a note of that, and effectively queues a re-rendering. The re-rendering takes place in the "redraw anything that needs it", at which time the code responsible for rendering can check current state and draw it red with a yellow border).

Quite a lot of what is "cool" about frameworks like React is the extent to which they are essentially trying to rebuild this fundamental event loop logic in a web app context.

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

#276

Post by acemarke »

PaulDavisThe1st wrote: post #273
rendall wrote: post #261

Earlier quoted context omitted.

How do these older frameworks (Qt, etc) approach state management?

Well, first of all, the problem in its most basic sense doesn't even really exist for many places where you would use "Qt, etc". You wouldn't be reacting with a remote server or if you are you have a stateful connection with the remote server. That's true whether the "remote server" is just a database server or something more specific. But going somewhat deeper (and based on reading all the defenses of "React, etc" i…

A few other differences:

- The classic desktop GUI frameworks (Qt, wxWidgets, MFC, Swing, WinForms, etc) are based on a completely OOP inheritance and ownership model. You are responsible for instantiating widget instances, configuring them via setters, appending them to parents, and likely cleaning them up as well.

- It's been long enough since I've done desktop GUI dev that I can't speak to the state management aspect much, but I can certainly say that at the time, my own programming understanding was limited enough that I would have said my "state" was "whatever items are currently inserted in that ListBox". (I knew that forms of data binding existed, but didn't grok them yet.) I do remember Swing's JTable widgets have a distinct MVC setup, at least.

- Web dev is _heavily_ concerned with the number of bytes being delivered over the wire, so it's not just the number of round trips, there's the obsession with trying to find the tiniest library that can do what you need (combined with the nonexistent JS standard lib). With the desktop? Who cares, let's link in 50MB of Qt DLLs! (yes, yes, insert Electron joke here.)

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

#277

Post by kerkeslager »

erikpukinskis wrote: post #235
PaulDavisThe1st wrote: post #224

So let me just check that I understand this correctly. A whole bunch of problems that were "solved" (or at least, had fairly good solutions) in the context of desktop GUI toolkits have resurfaced in the context of application development confined to the web browser. Almost none of the previous "solutions" are usable, because of the specifics of the theoretically portable "browser platform" for which all this developm…

All technology goes through two somewhat independent cycles, continuously : 1) The bloat cycle 2) The disruption cycle The bloat cycle is where you have a “platform” that does more and more until it has a lot of features that most users don’t need. Eventually the cost of supporting those random features gets too high and there is pressure on people to hack together an alternative micro-platform that does some arbitra…

It's so frustrating. React/JSX, and maybe Immer, is actually really good--it's revolutionized the way I write frontends. But I'm wary of bringing these tools into products, because I know that then I'll be having to constantly fight to not bring in whatever global state management nonsense people on my team discover first. If you stick around long enough you see global state systems collapse under their own weight into trashpiles of unintelligible code, but for the first quarter or so, it seems really simple to just pull the whole application into global state.

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

#278

Post by lhorie »

acemarke wrote: post #263
lhorie wrote: post #260

Earlier quoted context omitted.

Add a word after "react-" and there's a good chance it's one. React-bootstrap (vs bootstrap), react-dnd (vs something like dragula), etc.

I'm not sure what point you're trying to make here. Both of those examples are _specifically_ about using React to do the actual DOM manipulation. React-Bootstrap is a set of React components that know how to generate the correct HTML structure and classnames to get the matching Bootstrap styles. As part of that, I believe some of the jQuery-centric logic in Bootstrap has been implemented in just React. For drag and…

This is why I was reluctant to give examples (because as soon I did, someone was bound to say something along the lines of "well these leverage react in a very react specific way so of course it makes sense they're react things")

The thing is that we could s/react/jquery/ and end up with a more-or-less believable argument for why "jquery is needed for complex apps": You can't just `draggable=true`. jQuery wants you to describe your UI in terms of a plugin's options object rather than doing raw DOM manipulation; libraries like jquery-ui do the work to tie together drag events with underlying logic (e.g. snap) to drive jQuery re-rendering. You're not "using other libraries to do DOM manipulation"; jQuery's doing the work. Etc.

Of course a library on top of react/jquery/whatever will generally be written in a way that is idiomatic for code written on top of its respective base framework. For library writers like you and me, it might even make sense to argue that React rendering model is nicer for writing libraries on top of than jQuery. But that's a developer-oriented mindset, which, as the_gastropod had alluded to, it's very often at odds w/ a user-oriented mindset.

The "old beard" approach slices through all the abstraction layers and simply points out: huh, you don't need context and css-in-js and themes to do dark mode, plain CSS fits the bill. And when one resets assumptions enough times and start noticing more often than not that "complex" projects turn out to be glorified CRUD apps, one might indeed start to wonder if the abstractions are really as fitting for the task at hand as they should be.

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

#279

Post by flukus »

ncallaway wrote: post #274
the_gastropod wrote: post #196

Earlier quoted context omitted.

> it's to give the user quick and actionable feedback. Right.. But I think often times the difference is pretty overblown. Clicking "save" and getting that feedback in ~100ms is not, in my estimation, worth the massive extra overhead of using a front-end framework, duplicating your validation requirements, etc. If you're google or facebook or youtube or are otherwise printing money, go for it. But for the 99% of web…

> Right.. But I think often times the difference is pretty overblown. Clicking "save" and getting that feedback in ~100ms is not Let's say the form has 5 fields, and I as the user make an error in the first field. Why do I have to finish filling out the entire form to hit "save", to discover I made an error in the first field? That's not a difference of ~100ms, that's a difference of several seconds (or tens of secon…

>Why do I have to finish filling out the entire form to hit "save", to discover I made an error in the first field?

Because more validation will usually happen on the server side anyway and finding out when you hit save creates less interruptions to your flow. There's no tabbing back to re-enter a field, there's no thinking it's fine only for the server side validation to reject it and there's no nagging when I skip a field to come back to it later, there's no UI jumping around when the error is shown. Client side validation takes a stateless form and interrupts me with it's stateful validation. At best it's an interruption, all too often there are silly things like not letting you tab to the next field or warning you that the second password you haven't yet entered doesn't match (and then later telling you about other problems when the backend does the validation).

Not to mention it's easier, whether you agree or not with "developers are expensive so performance doesn't matter" in a world where this is often said I'd expect more server side only validation because client side validation is duplicating the work.

I don't think client side validation is necessarily bad, but most implementations get in my way more than the server side equivalent.

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

#280

Post by wruza »

PaulDavisThe1st wrote: post #273
rendall wrote: post #261

Earlier quoted context omitted.

How do these older frameworks (Qt, etc) approach state management?

Well, first of all, the problem in its most basic sense doesn't even really exist for many places where you would use "Qt, etc". You wouldn't be reacting with a remote server or if you are you have a stateful connection with the remote server. That's true whether the "remote server" is just a database server or something more specific. But going somewhat deeper (and based on reading all the defenses of "React, etc" i…

>if you were using a desktop GUI toolkit, you would almost certainly assume that there's essentially zero cost (or almost neglible cost) to the communication between the data (model) and the GUI

Which is true, because model is what you’re working with and binding to (along with a controller). You can populate your models from a roundtrip data source, if it is not local. How is that different from web apps?

I think this is the good old “ancients were less smart” stereotype. Client-server and 3-tier apps didn’t begin with web. Heck, even lan latency/throughput/cpuclock were comparable to what modern internet timings impose.

Post reply on HN