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

311–320 of 335 posts

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

#311

Post by k__ »

FpUser wrote: post #308
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 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…

How big is your team?

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

#312

Post by dragonwriter »

the_gastropod wrote: post #203
nohuhu wrote: post #201

Earlier quoted context omitted.

> The server still needs to validate, no? Client input should never be trusted. Server needs to validate, but that doesn't mean client shouldn't validate as well. > 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. Client side validation is not only about required fields, it's much more than that. Have yo…

> Client side validation is not only about required fields, it's much more than that. Have you ever used a web store where you need to enter your shipping address, credit card info, etc? Address, zip code (or worse, UK style postal code), phone number, email, credit card number - all that needs to be validated. A couple points: 1. The ~100ms between submitting a form and getting error messages isn't that big of a hur…

> The ~100ms between submitting a form and getting error messages isn't that big of a hurdle, in my experience

Sure, it's the >100ms between the user entering the first value that might have an error and the user submitting the form that's a much bigger problem between validate-on-server-on-submit and validate-on-client-on-entry.

> But I don't agree React _benefits_ developer productivity. On the contrary, I think it (and its competitor frameworks) are responsible for a lot of wasted developer time and frustration.

After a not-very-long familiarization period, developers seem to be more productive with React (or probably Angular.) I know I am, and I've been using SPA frameworks (mostly React) for a short time after having done web lots of other ways for a very long time.

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

#313

Post by the_gastropod »

dragonwriter wrote: post #312
the_gastropod wrote: post #203

Earlier quoted context omitted.

> Client side validation is not only about required fields, it's much more than that. Have you ever used a web store where you need to enter your shipping address, credit card info, etc? Address, zip code (or worse, UK style postal code), phone number, email, credit card number - all that needs to be validated. A couple points: 1. The ~100ms between submitting a form and getting error messages isn't that big of a hur…

> The ~100ms between submitting a form and getting error messages isn't that big of a hurdle, in my experience Sure, it's the >100ms between the user entering the first value that might have an error and the user submitting the form that's a much bigger problem between validate-on-server-on-submit and validate-on-client-on-entry. > But I don't agree React _benefits_ developer productivity. On the contrary, I think it…

I've been professionally working on SPAs for the past 7 years. I'm familiar. I strongly disagree with the premise that it's in any way more productive. I'm, at a minimum, 2x more productive building something the traditional "Rails way" with server-rendered HTML, and a handful of JS enhancements where necessary vs doing a full-blown SPA. I'd love to do a showdown, and challenge anyone to a head-to-head non-trivial app build-off to put these competing notions to the test.

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

#314

Post by dgb23 »

untog wrote: post #222
dgb23 wrote: post #217

Earlier quoted context omitted.

>So you’re wasting download and JS processing time (a serious concern on low end devices) hydrating a lot of elements that won’t even ever change. It’s stupid and it needs to stop. You hydrate the markup because you want to render subsequent state changes in the client. Meaning much smaller downloads (just the relevant data) between route changes and so on.

That’s often a bad bet though. Obviously it depends on what kind of site you’re operating but a lot of places have a very steep drop off after a single page view. If that’s your case then you’re optimising for an edge case at the expense of the majority.

I see you concern but right off the bat here is a very good example of where this kind of frontend pattern works very well, even for site that is essentially just static content from a user perspective:

https://reactjs.org/

I suggest you open the network inspector and see what happens when you hover over links, navigate and so on. The experience is very fast and responsive on initial page loads and even faster on subsequent navigation:

The initial page load is as fast despite of hydration because many of the requests are non-blocking and/or happen after the raw page content is loaded, including JS scripts.

Further navigation triggered loads just load small amounts of JSON while many of the assets and common UI elements are already there. In this case the data is even loaded while you hover over a navigation link.

Yes, this assumes that you actually navigate through the site and yes it does more than you sometimes need if you just view a single page.

But the trade-off seems to be very good here from my perspective, especially because one cannot know if the visitor will navigate on the site past the initial page load or not. The content on this site is also structured into small subject-pages (see: the docs sections), which synergizes well with this frontend pattern.

On top of that comes ease of development, tooling and automation around the react ecosystem (you'll find similar in other frameworks). And the mere fact that there is much less coupling between the rendering/gui side and the data/server side, even though most of the site is rendered on a server, because the frontend code lives in one cohesive framework.

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

#315

Post by untog »

dgb23 wrote: post #314
untog wrote: post #222

Earlier quoted context omitted.

That’s often a bad bet though. Obviously it depends on what kind of site you’re operating but a lot of places have a very steep drop off after a single page view. If that’s your case then you’re optimising for an edge case at the expense of the majority.

I see you concern but right off the bat here is a very good example of where this kind of frontend pattern works very well, even for site that is essentially just static content from a user perspective: https://reactjs.org/ I suggest you open the network inspector and see what happens when you hover over links, navigate and so on. The experience is very fast and responsive on initial page loads and even faster on sub…

Perhaps unsuprisingly, React's own web site is a great example of how to do React right. By the looks of it it's not loading the entire page into Virtual DOM, it's got code splitting, loading on demand... all the absolutely right things.

A lot of React sites I see in the wild have none of this. They have a multi-MB JS blob that gets downloaded immediately on load and parses a giant JSON blob stored in the HTML that represents the page state.

I'm not saying React isn't useful or that it can't be done well. I'm saying that in a lot of cases it just isn't done well. Whether that's down to a lack of education or a lack of care I don't know.

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

#316

Post by int_19h »

k__ wrote: post #304
int_19h wrote: post #241

Earlier quoted context omitted.

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

GUI designers of the RAD era were much easier than Photoshop or Flash, and certainly easier than writing it out by hand. That's precisely why they became so popular.

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

#317

Post by icedchai »

rossmohax wrote: post #216

I know nothing about state management on frontend, but please make supporting "history back", "history forward" and "F5 reload" use cases easier. It seems to be a hard problem to crack, given how often these simple actions are broken

SPAs have created an "inner platform" effect. Developers are forced to recreate / provide basic browser functionality.

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

#318

Post by k__ »

int_19h wrote: post #316
k__ wrote: post #304

Earlier quoted context omitted.

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

GUI designers of the RAD era were much easier than Photoshop or Flash, and certainly easier than writing it out by hand. That's precisely why they became so popular.

But why didn't they stay popular?

Did the Flash disaster cast fear into people?

Did Web-tech based systems perform so much better, business wise, than native desktop apps?

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

#319

Post by veeralpatel979 »

nojvek wrote: post #302

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.

Hey - author here.

I agree that libraries for certain things, like MobX/Redux or Formik, may be overkill.

What's more important, though, is that people choose an appropriate equivalent to these libraries. Replace the library, but not the method of organizing state.

For example, feel free to replace MobX/Redux in my post with your own global state management solution. But I recommend replacing it with a global state management solution, not something else.

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

#320

Post by veeralpatel979 »

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…

Hi - author here. I haven't used react-easy-state unfortunately. But like when building a company, the best product doesn't always win: the company that executes the best does.

Executing well includes building a great product, but it also requires marketing, which the Redux community has done a great job of to the point where it's the de facto solution.

Post reply on HN