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

261–270 of 335 posts

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

#261

Post by rendall »

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…

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

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

#262

Post by jrochkind1 »

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…

well said and insightful I think!

I think these cycles are just results of human social behavior around software platform technology; whether they have a point or are pointless -- they can be either. Sometimes it's two steps back one step forward, other times the reverse.

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

#263

Post by acemarke »

lhorie wrote: post #260
westoncb wrote: post #220

Earlier quoted context omitted.

> 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. Could you give an example of a commonly-used library that serves this purpose?

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 drop especially, you're having to approach the problem from a different mental model. You can't just `$(".my-list").sortable()`. React wants you to describe your UI based on _state_ rather than doing raw DOM manipulation, so libraries like react-dnd and react-beautiful-dnd do the work to tie together drag events with the underlying logic to drive React re-rendering.

But in both these cases, you're not "using other libraries to do DOM manipulation". React's doing the work. These libraries are just helping tell React what the DOM should be.

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

#264

Post by zelly »

bernawil wrote: post #114
zelly wrote: post #80

Earlier quoted context omitted.

Don't overthink it. Native HTML5 elements come with form validation and even a way to serialize (!) and submit form data w/ action and method attributes. (To implement the same as React components would be a 3 month project coming with a 1 GiB node_modules dir.) The only time you have to add JS bloat is for date pickers and time pickers which aren't supported on Safari yet (and you can user agent sniff for this). Blo…

People need way more validations than html5 elements can provide. They need CC number validation. Validations that depend on the content of sibling elements. And they need it to display in custom ways like internationalized or whatever.

Attach event listeners and handle those parts with JS. For internationalization, template on the server side, sending a different bundle for user agents in different countries. CSS is enough to fill the gaps with other internationalization concerns like rtl.

The platform provides enough to do forms. It's one of the few things the web is good at. It has been around for ages and works. I mean, what I'm using to type this is a plain HTML form. It doesn't need a massive JavaScript framework that heats up my CPU on every keystroke.

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

#265

Post by zelly »

acemarke wrote: post #98
zelly wrote: post #86

Earlier quoted context omitted.

Having everything in global state is cheap if you use Immutable.js data structures. In my experience, Immutable.js the only way to do the global store pattern e.g. Redux without making your app slow to a crawl.

Note that we specifically recommend _against_ using Immutable.js, and that there's many misunderstandings about the hypothetical performance benefits that Immutable.js provides: https://redux.js.org/style-guide/style-guide#use-plain-javas... Instead, we strongly recommend using Immer for immutable update logic, preferably as part of our new Redux Toolkit package: https://redux.js.org/style-guide/style-guide#use-immer…

I didn't know about this new library but from my benchmarks it was a night and day difference moving to Immutable data structures all the way down. I understand not wanting to recommend it to newbies, but it's actually good.

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

#266

Post by kerkeslager »

> For example, say your app has a dark mode. All your rendered components must know what theme is on, so they can render the UI in the right color.

Wait, what? Hell no. This is literally the core use case for CSS classes. And while there are cases where CSS classes can cause problems, this isn't one of them. This is a case where CSS classes shine.

This is like an article on how to use fire to solve problems, and instead of choosing an example like staying warm or cooking food, the author leads with an example like disposing of tires by burning them in the rainforest. It's just an unambiguously bad idea.

There were a bunch of places where I wasn't familiar with the tools he's using and am curious, but I'm certainly suspicious of anything he suggests after the "use global state to reinvent CSS classes via JS" suggestion.

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

#267

Post by acemarke »

zelly wrote: post #265
acemarke wrote: post #98

Earlier quoted context omitted.

Note that we specifically recommend _against_ using Immutable.js, and that there's many misunderstandings about the hypothetical performance benefits that Immutable.js provides: https://redux.js.org/style-guide/style-guide#use-plain-javas... Instead, we strongly recommend using Immer for immutable update logic, preferably as part of our new Redux Toolkit package: https://redux.js.org/style-guide/style-guide#use-immer…

I didn't know about this new library but from my benchmarks it was a night and day difference moving to Immutable data structures all the way down. I understand not wanting to recommend it to newbies, but it's actually good.

If you can take a few minutes to read through https://redux.js.org/style-guide/style-guide#use-plain-javas... , and specifically the "Detailed Explanation" section there, I talked through all the perceived and actual perf benefits that you see with Immutable.js.

In short, most of the benefits people _think_ they get from Immutable.js are just properties of immutable updates in general, and there's actually some pitfalls of using it. The only real unique benefit is faster copies of _very_ large objects.

I'm not saying it's not helpful, just that it's not a silver bullet in and of itself the way some folks think it is, and that you can get similar benefits without the overhead of its API.

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

#268

Post by austincheney »

kerkeslager wrote: post #266

> For example, say your app has a dark mode. All your rendered components must know what theme is on, so they can render the UI in the right color. Wait, what? Hell no. This is literally the core use case for CSS classes. And while there are cases where CSS classes can cause problems, this isn't one of them. This is a case where CSS classes shine . This is like an article on how to use fire to solve problems, and ins…

Yeah, I have a stylesheet for layout and then one for each color scheme. Changing the scheme is literally changing the class attribute of the body tag.

Maintaining state isn’t that much harder.

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

#269

Post by FpUser »

spookthesunset wrote: post #99
itronitron wrote: post #62

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. That was nice because it was relatively easy for anyone to trace through the application as needed. In my experience if the application state is overly complex then that is a result of the design, and that usually leads to a bad experience for the user.

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

Not directly related to web front end but having extensive developer experience I tend to shy big frameworks (with a couple of exceptions) . Instead I am using set of battle proven libraries that change depending on needs.

My reasons are:

  I do not need to learn a monster
  If framework goes down/becomes unpopular etc. etc. I could care less
  Libraries are easily abstracted and replaceable.
Yes I/team do end up implementing our own framework but this framework is very tiny comparatively to you common monstrous frameworks and any sane person can get a grip in a day or less and it only has enough to accomplish a project.

Also it can be easily sliced/diced and needed accumulated bits and pieces can be used for next project.

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

#270

Post by austincheney »

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…

> Almost none of the previous "solutions" are usable, because

No, it’s because developers are shamed and generally unemployable for writing code that doesn’t make use of a colossal super framework.

Post reply on HN