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

281–290 of 335 posts

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

#281

Post by kungtotte »

veeralpatel979 wrote: post #170
bcrosby95 wrote: post #63

Earlier quoted context omitted.

I find lots of these "requirements" come from developers that are bored with their job and need to spice things up.

Maybe! But also, as a user, I expect to do more and more in my browser. I would find it strange, and probably switch to a competitor, if my preferred airline for example made me install (and keep updated) a desktop app in order to book a flight.

You do. Not everyone.

You know one thing I expect my browser to do that it has a hard time doing these days? Efficiently and correctly displaying text documents.

It has a hard time doing this because so many web pages think they need to be web apps and overthink things instead of leveraging the tools at their disposal in the browser.

Yes, if you're building a new Outlook or Google Maps in the browser it ought to be a web app.

If you're building the remaining 90% of use cases it should probably just be a web page with boring old tech. Add JS for spice if you'd like.

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

#282

Post by PaulDavisThe1st »

wruza wrote: post #280
PaulDavisThe1st wrote: post #273

Earlier quoted context omitted.

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

Some of what you've said here strikes me as true, as long as you limit the domain to "applications" aka "database client-server front end foobars".

It's really not true for any desktops in the "creation" realms that I mentioned. The data model for an image manipulation program or a spreadsheet or a DAW or a document preparation system is fundamentally in memory, and there's no roundtrip to anywhere to access it or to modify it.

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

#283

Post by ncallaway »

flukus wrote: post #279
ncallaway wrote: post #274

Earlier quoted context omitted.

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

> all too often there are silly things like not letting you tab to the next field

Well, that's a criminal use of client-side validation, but it shouldn't condemn all client-side 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.

That's fair, but as others have noted if you're in a world where a polished user-experience really makes a difference or is a competitive advantage I'd argue that well executed client-side validation can get you to a UX-quality bar that no amount of server-side validation can reach (edit to add: server-side validation is still, of course, absolutely required).

Whether that's truly important for a given business or product can only be argued on a case-by-case basis. I think it's definitely a colorable argument that there's some overuse of client-side validation relative to product goals, but I think there are definitely places where client-side validation is hugely impactful.

Again, all of this assumes that the client-side validation is implemented at a high quality bar. Of course bad client-side validation is not useful.

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

#284

Post by hippich »

PaulDavisThe1st wrote: post #275
rendall wrote: post #261

Earlier quoted context omitted.

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

It is pretty much the same, except there is no explicit loop and calls to wait for events written in JS/React code. Javascript itself runs a loop, instead of polling for events, you define events handlers, and DOM/React handles "redraw anything that needs it" part.

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

#285

Post by jeffadotio »

I have abandoned all of the JavaScript state management libraries and now prefer to simply write my own storage module using Meiosis[1] and a tiny library for operating streams. This replaces tech debt and repetitious boilerplate code with simple, meaningful and functional code.

http://meiosis.js.org/

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

#286

Post by ng12 »

danellis wrote: post #199

Why is state management such a talked-about issue with React? Other than distributed state, which obviously comes with its own set of challenges, managing state doesn't seem to be an issue with any other language, framework or platform. But with React, it seems to be a major part of the learning curve, with entire tutorials dedicated to it and numerous libraries to help with it in some way.

Because managing state is really the major unsolved problem in front-end. No framework has it really solved -- but in React (and Vue) the other stuff is so easy that the issue of state management because much more pronounced.

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

#287

Post by jrandm »

imtringued wrote: post #239
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…

I would like to see a chat application implemented with just forms that submits stuff. How are you going to get new messages?

I got sidetracked searching for pictures of the multiplayer part of the game Vagabond's Quest.[0] I wasn't successful, unfortunately, but a number of the pages outside the login wall were archived.[1]

I think you might find several of these pages entertaining,[2] especially if you're familiar with text-based games (especially MUDs and MOOs[3]) and a Dungeons and Dragons-esque setting. The items, combat (PvP and 1-player), and any other aspect of chance were transparently dice rolls and modifiers in-game.

Because this is Hacker News, don't miss out on the >20-year-old anti-hacking mechanism.[4][5] Keep in mind this is for a sequel or companion game that came (IIRC years) after the original.

With that stage set, picture a black background and some grey text with scattered red/green/blue highlights. The logo was probably the only image. The page would reload every few seconds, but you could manually reload and see new messages sooner. If your username was in a chat text it would make the text larger (both the line and your name, I think).[6] Maybe under a few other conditions too: if you were fighting someone, if it was the admin/mod/dev(!) Falados, I think you could add a few of your own word filters at some point. Originally it was just your username in the line, I'm pretty sure. The combat moves and rolls were also part of this chat stream. I remember being in busy rooms with dozens of people, frantically refreshing, trying to read the top of the screen quickly before it was lost.

It was great!

I hadn't quite connected the games to programming yet, but I imagine the Hall or Arena you "joined" for Player vs Player combat and chat was by visiting the page of HTML generated by Perl scripts (I remember URIs ending in .pl, maybe some CGI thing?) that had a meta tag to trigger the refresh. It had a regular form with a submit button and the page reload was convenient because that was the only way to see your message or anyone else's new in the page.

I'm amazed how clearly I remember playing, if the details are a bit fuzzy. Looking for pictures I came across this,[7] and am excited to read through and maybe check out a beta. Thanks for prompting the search!

[0]: http://www.angelfire.com/games2/LanderZ/vq.html

[1]: https://web.archive.org/web/20000818004717/http://www.netdra...

[2]: https://web.archive.org/web/19990902013706/http://www.netdra...

[3]: https://en.wikipedia.org/wiki/MOO

[4]: https://web.archive.org/web/19991105152436/http://www.netdra...

[5]: https://crypto.stackexchange.com/questions/47177/would-sha1-...

[6]: FONT tags, I'm 99% sure. This was probably one of my early view-source learn-by-example sources, in a futile attempt to cheat

[7]: https://playvq.com/roadmap/

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

#288

Post by mesaframe »

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…

Is JavaScript is a need making a library/framework over it doesn't make it any better.

Also, you stated benefits of Fact without stating how it makes it better.

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

#289

Post by bluebill1049 »

breytex wrote: post #14
vga805 wrote: post #8

What's the deal with the recommendation to use some library for managing forms? I've been working with React almost since its initial release and I've built some pretty complex forms... yet form libraries remain the one thing I've never really seen a need for. At the very least, using something like formik shouldn't be a necessity. There should be some qualifier that it's only really needed for very complex forms. Or…

I felt exactly the same for many years, but when hooks where introduced, I discovered react-hook-form [1]. It just blew my mind how you can write complex forms with validations in just a few lines of code. Give it a try. [1] https://github.com/react-hook-form/react-hook-form

Thanks very much for sharing ️

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

#290

Post by monocasa »

danellis wrote: post #237
acemarke wrote: post #200

Earlier quoted context omitted.

Because React, more so than the other frameworks, puts such a strong emphasis on "the UI output is entirely based on your state", while at the same time there are some limitations to tracking state in ways that are inherently tied to your UI hierarchy.

> the UI output is entirely based on your state How could anything else be true?

What they're saying is that there was no clear separation between model view and controller. Now they've really embraced view (React) as a pure function of model (Redux) that has very clear way that events modify state coming from the controller (your business logic).
Post reply on HN