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

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

Sure the server can (and should) validate that. The problem then is how to let the user know they've made a mistake and how to fix it. Accessibility issues aside, users need to be told that they've made a mistake as soon as it is made, otherwise there is a chance they won't find the error message, and simply give up trying. Lost sales is the reason client side validation was invented.

> Hmm? What about them needs React?

If you don't want to submit a form with full page reload, you need to make an Ajax call with form info. When response comes back with a list of errors, you need to walk through the fields on the page and mark the relevant ones as invalid, with corresponding error messages displayed _close_ to the input fields. Of course that is doable in plain JavaScript, and doing that seems trivial for one form. Then you have to duplicate that code for another form, or abstract it in a library... Congrats, you're on your way to reinventing React. Or worse yet, Angular.

> You can poll very cheaply. And even Websockets are pretty simple.

When the results of that poll come back, you need a way to display them. You need to decide which part goes where, which elements to hide and which to create, etc. The mechanics of this is what React (or a similar library) does for you, so that you could concentrate on writing logic instead.

> We're talking about React being overkill in a lot of places.

React might be overkill in a lot of places, but it's extremely hard to tell where and when. If you start with a simple hand rolled JavaScript app, at some point you might realize that maintaining it is a chore beyond one person's capacity, and hiring someone to do that for you is plainly impossible. You should have started with (React|Angular|Vue|whatever) in the first place, and now it's a choice between ground up rewrite in (React|Angular|Vue|whatever), or long stagnation and eventual death of your business. Do you want to take that chance?

Optimizing for developer productivity is the only safe bet in the majority of cases, unless we're talking about a personal project with no commercial value.

> 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 hurdle, in my experience.

2. HTML5 has validation attributes for forms, which can handle every one of your examples.

> If you don't want to submit a form with full page reload, you need to make an Ajax call with form info. When response comes back with a list of errors, you need to walk through the fields on the page and mark the relevant ones as invalid, with corresponding error messages displayed _close_ to the input fields. Of course that is doable in plain JavaScript, and doing that seems trivial for one form. Then you have to duplicate that code for another form, or abstract it in a library... Congrats, you're on your way to reinventing React. Or worse yet, Angular.

Negative. You can do an ajax call, and re-render part of the page (e.g., the entire pjax-style). This is fast, doesn't cause the "flash" of a page reload, and doesn't require more than a few lines of js to setup.

> When the results of that poll come back, you need a way to display them. You need to decide which part goes where, which elements to hide and which to create, etc. The mechanics of this is what React (or a similar library) does for you, so that you could concentrate on writing logic instead.

Again, turbolinks on pjax has solved this problem very well. Just re-draw the bulk of the page. All the simplicity of reloading the page with none of the user pains of actually reloading the page.

> Optimizing for developer productivity is the only safe bet in the majority of cases, unless we're talking about a personal project with no commercial value.

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

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

Is it worth spending more developer time (think $$) on optimizing things for imaginary savings on initial page load time?

> Right.. But so is just re-loading (most of) the page from the server. Again, e.g., Phoenix Live View or Action Cable style.

How is that less complex than a client side application? You are essentially advocating for splitting the logic between server and client side. Of course that is possible and people do that all the time for various reasons. Does not mean that's the best way of doing things.

I think you are missing the elephant in the room. Emergence of the front end development frameworks like React was caused by ever increasing complexity of the front end applications. Which, in turn, is driven by customer demand. Customers pay for features, not for code quality, and churning out features is much easier and quicker using React vs. e.g. jQuery.

Lamenting front end application overhead is the same as lamenting using high level languages for back end services. Everybody knows that Real Programmers wrote Real Programs in assembler back in the olden days!

Is it just me or does the state management / prop-drilling thing sound just like a bog standard dependency injection problem?

This seems like a strange example since being able to book flights in your web browser predates any Javascript "frontend framework".