If you're using redux, I can't recommend redux-form enough. It's genuinely one of the best designed libraries I've ever used, including other languages/stacks etc. I think a little hard to grok at first but once it clicks you realise that it's such an elegant way to manage all form state you could ever have a need for, and it just works out the box.

Comes with an inbuilt validation mechanism in the form of a function with errors piped through to fields etc, if that's what you meant? The actual validations you have to write yourself though. I typically do this by hand/regex rather than use a library for that on the client, to be honest, as it's usually pretty simple.

Hi, I'm a Redux maintainer. I would generally recommend _against_ using Redux-Form in almost all cases - it's really not necessary. Most forms can be handled by hand, or with a React-centric form library if you want to abstract that.

I actually just wrote a new Redux FAQ entry yesterday on "should I keep form state in Redux?"

https://redux.js.org/faq/organizingstate#should-i-put-form-s...

I can see how performance might be a concern but I've never run up against issues with this in my own implementations using redux-form. Maybe if you do some exotic stuff it could be a problem, but yeah, never had an issue with this.

What I do love is the use of redux dev tooling -- for literally every action on my form, I have a log of when it occurred and how exactly it affected the state of the form. This is simply awesome. Yes, there are probably ways to do the same thing with a non-redux implementation, but if I'm already using redux I get this for free in the same tooling I already know and love.

For what it's worth, I have in the past (before understanding the tradeoffs of where redux state vs component state makes more sense and trying to do everything completely 'purely' in redux state) foolishly tried to keep all inputs and other UI components' state in the redux store, in a completely hand-written element id based mess. I totally agree with the sentiment that it's not necessary or worth the effort to manage one-off component state in redux in the general case.

However in this specific case, redux-form encapsulates and manages all of that complexity and you don't have to think about it at all. Actually ironically other than the redux dev tools part I don't really care about the 'in redux' part. I just like the library and its API.

Sure - if you've evaluated the tradeoffs and feel that using Redux-Form is beneficial for you, go for it! I've just seen a lot of people answer questions of "How do I work with forms in React?" by blindly saying "USE REDUX-FORM!", and that's just... no. Totally not necessary. (Right up there with "adding two numbers in JS by using jQuery".)

The author of redux-form created another library, final-form, that doesn’t need redux or react and has most of the features of redux form and has built in lessons he learned from writing redux-form. There’s a separate React-final-form package with easy React bindings as well if you’re using them together. It’s worth a look as well (I’ve used both).

https://github.com/final-form ?

Ah, thanks, wasn't aware of this and will certainly check it out!

Redux-forms has lots of performance issues, and is now considered a relic of the days when everyone was drinking the Redux kool-aid. Formik is a very popular alternative: https://github.com/jaredpalmer/formik

Only with Javascript can a project that's a scant three years old from its first ever commit be called a "relic". :-)

For React forms and validation the combo of Formik and Yup is quite nice. Formik takes a schema prop specifically for integration with Yup, it's covered in the docs.

https://github.com/jaredpalmer/formik

https://github.com/jquense/yup

Formik was nice until I have to do complex logic that needs access to the form outside the component.

react-final-form simply blew my mind after I had to deal with that horrible reactive angular forms... It also works pretty well in tandem with redux

Depending on how well you do the treeshaking, all dependencies that are not in use will be removed from the bundle.

I do not know how agressive the angular CLI settings for webpack are, but with our own config we are removing any noise really effectively

Also, you can use a tool like https://www.npmjs.com/package/source-map-explorer to see if there's code in your bundle you don't expect!

In Ember3.0+ you can strip down the framework all the way to just the rendering engine if you would like. It's all modular now.