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

301–310 of 335 posts

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

#301

Post by littlecranky67 »

dragonsh wrote: post #254
radlad wrote: post #182

Earlier quoted context omitted.

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.

Having used react and modern web components to build webpages. I will agree with the first comment which says what is made so hard by react/redux can be easily done if the pages were rendered on server and delivered to client with progressive smaller bits of JavaScript for dynamic interaction. If state management is so critical to running a react app than I feel Elm/ClojureScript is a better choice than react to buil…

> Now everyone went on a bandwagon that react/angular/SPA/progressive apps is the only future and plain HTML/CSS/JS mix on server side with specific language templates is dead

Well it is not dead, but with the rise of Webapps (not Websites!) come use-cases you can only handle with SPAs. One major example is the new youtube feature, where the video playback is not interrupted when you click on a link somewhere (the video stays at the right bottom corner of the page and keeps plaing). No way to do this with SSR.

Other examples include staying in fullscreen mode (think automatic playback of video playlists) - with SSR, every video change would trigger a page reload and thus require user interaction to go back to fullscreen.

SPAs are not required for Websites, but for Webapps there are a lot of cases where SSR is not possible or would result in poor UX.

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

#302

Post by nojvek »

This post is overly complex in its suggestion of libraries. He does have a good point of understanding different kinds of state and that state management in front end is perhaps the hardest problem. If you think about it well earlier, a lot of things become easier as you scale.

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

#303

Post by k__ »

veeralpatel979 wrote: post #204
k__ wrote: post #202

Earlier quoted context omitted.

I used CSS frameworks for theming.

Ok; ignore that specific example -- if you needed to share a piece of state among many components in different places in your component tree, how would you do it?

I have 3 tiers of components.

Root - Page/Screen - UI Elements

The Root takes care of authorization and navigation logic, to switch between pages.

A Page has all the logic needed for one page it holds all the state and passes it down via props.

A UI Element displays the state it got via props and sends up its events via handler function (it also gets them via props)

In 90% if cases this was enough.

Sometimes, I needed to pass some state from the Page up to the Root and from there down to another Page after navigation, but that was it.

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

#304

Post by k__ »

int_19h wrote: post #241
k__ wrote: post #104

Earlier quoted context omitted.

"is React simpler for building UIs than the RAD tooling of Visual Basic, Delphi or the Flash Designer" I asked something like this too, but the other way around. "If Flash, Delphi, etc. were so good, where are they now?" The answers were: These tools were good for one developer or small teams, but textual dev tools scaled better to big teams.

Delphi is "textual" as well - the designer works with text files (*.dfm) that describe the component tree. Very similar to JSON, but with more Pascal-like syntax. People mostly used the designer because it was easier - but then again, in that era, it was also common for people to use e.g. Dreamweaver to write HTML.

Maybe, getting into development got easier?

I mean, while these graphical tools certainly help, you have to learn them. I learned things like Photoshop, Sketch, Ableton Live, Final Cut Pro, Eclipse, etc. pp. and I can tell that it's a huge time investment to get up and running.

Maybe coding is that much easier, that people invest their time into this instead of a UI builder?

Maybe people got burned by Flash and now want to invest into somthing that lasts longer?

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

#305

Post by sparkywolf »

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…

https://imgur.com/gallery/91sn32Q

On a serious note, I do agree with you. oftentimes things are overcomplicated just for the sake of 'javascript'. Once you get used to setting up a project a certain way you may not stop to consider whether or not it's the best for the specific project.

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

#306

Post by FpUser »

andrewstuart wrote: post #234
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…

I don't think this is correct. I don't believe the concept of one way data flow was in the old desktop app approach was it? Nor was the idea of "props" i.e. a consistent mechanism for pushing parameters down to subcomponents through a consistent and flexible interface. Nor was the idea of the render function - giving components a consistent function used to display itself. Also gigantic leaps are being made in the ar…

"Old desktop applications, because they did not have a core application "cycle/flow" and were not arranged as a tree of components,"

I am not sure where did you get this idea. Delphi had it like almost 30 years ago.

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

#307

Post by untog »

IggleSniggle wrote: post #180
untog wrote: post #72

Earlier quoted context omitted.

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…

...aren't the static portions uh...rendered server side? And possibly even the dynamic ones cached when common? If not, I'm confused about what SSR means in this scenario.

They are rendered statically... then hydrated client side, needlessly, because they’ll never change.

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

#308

Post by FpUser »

k__ wrote: post #104
goatlover wrote: post #33

Earlier quoted context omitted.

But is React simpler for building UIs than the RAD tooling of Visual Basic, Delphi or the Flash Designer? Obviously there is the advantage of the web platform to leverage with JS frameworks, but there was something really nice about being able to drag and drop standard controls that all users were familiar with, and then just attach some code to them that talked to a database or whatever. I think that was the Parent'…

"is React simpler for building UIs than the RAD tooling of Visual Basic, Delphi or the Flash Designer" I asked something like this too, but the other way around. "If Flash, Delphi, etc. were so good, where are they now?" The answers were: These tools were good for one developer or small teams, but textual dev tools scaled better to big teams.

Delphi and it's opensource cousin Lazarus/Freepascal are doing just fine and I use those to implement desktop applications. Single exe with no dependencies. Beauty. Sure they're not popular in North America but I could care less. Those tools save me a boatload of time. There is also QT.

"The answers were: These tools were good for one developer or small teams, but textual dev tools scaled better to big teams."

Utter nonsense. They scale just fine. Whoever gave the answer seem to not know what he/she is talking about.

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

#309

Post by ncallaway »

wilsonrocks wrote: post #293
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…

There is definitely a happy middle ground. Feedback too soon can be jarring, but waiting till the end of a form can be very frustrating, especially if there are many fields and you have to reparse to find the error. I think you need both to have a good experience.

Oh, I agree.

I just think that, if you're aiming for the highest UX-bar, you're going to need client-side validation at some point. For any mildly complex form, server-side validation will usually be far past the sweet-spot you're referring to.

Now, as others have mentioned, it might be questionable whether every web-app and website should be targeting the highest UX-bar.

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

#310

Post by dragonwriter »

lhorie wrote: post #128
jfengel wrote: post #47

Earlier quoted context omitted.

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…

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

A decent dark mode is going to take a lot than a class at the root in any case (a class at the root makes a good toggle, sure, but you have to do all the styling if particular elements that that toggle applies.)

If you have handrolled CSS for your light theme and want to add a dark theme toggle, hand rolling CSS for it and toggling with a class at the root is pretty idiomatic React.

If you've chosen a styling/theming library to solve other problems, or incidentally to doing so as might have happened if you chose Material-UI, then, sure, a class at the root might not work well, and/or you might have a much easier solution (not easier than the class at root but easier than the rest of the work of implementing a dark theme) for adding a toggleable dark theme. Like in Material-UI, where you just tell the theming solution you’d like the computed dark version of a theme.

Post reply on HN