Question regarding this vs. redux-form about react-reformed HOT 5 CLOSED

Absolutely I will if I come across them, thank you. I'll be incorporating it into my first form probably Sunday so if you don't hear from me by weekends end then everything went smoothly :)

from react-reformed.

Sorry for the essay, I started typing and just never stopped.

The difference between reformed and something that ties into the larger redux application state (a la redux-form) is that those change events are scoped to the reformed lifecycle (until you reach outside of it, perhaps to cache/sync form state [which can be debounced to limit its effect]).

As you know, a dispatched action will flow through all reducers (and middleware, and whatever else), which will then in turn call all connected components. This is where redux-form@v5 operated. If you've got a form big enough to cause performance issues on re-renders, you probably have an application with a bunch of other reducers and connected component renders that are nooping (even efficiently) during each form change. How significant these are depends on the application, but the point stands that reformed causes less turmoil out of the box, since its change events are limited to a local state change.

So yes, the entire form is re-rendering, and yes, there could very well be issues down the line. That said, I'd argue that it would be less likely and would probably take longer to experience any problems. Reformed, combined with pure components (optimized with shouldComponentUpdate) should be pretty damn efficient. After all, the point of React is that your UI is just a function of application state, so its built to handle this extremely effectively. I haven't followed redux-form that extensively, so these ideas have probably already been discussed and found to be inadequate, but I stand by the fact that reformed should have a smaller footprint in your application.

Ultimately, it's important to remember that this library is not meant to replace redux-form, since those guys and gals have pored a ton of time into the library and I'm sure have made the API decisions they have for a reason. The core of react-reformed is < 100 lines of code, so it's not going to be a magic bullet that will guarantee flawless performance at a massive scale (keyword being massive). This impetus for this project more comes from a distaste for incorporating fairly sizable, broad-brush libraries to do things that could be implemented on a small scale tailored for your precise needs, and I just wanted to share this as an alternate approach more than anything.

What I would say is that you're far less likely to pigeon-hole yourself using a lighter weight library (if you can even call this a library) than to lean heavily on a larger abstraction that will be harder to remove or change in the future. And, if you're at the point where re-rendering is causing noticeable performance issues, it's likely time for a solution specifically targeted at your exact needs, not another broad brush stroke that should hopefully fix it. I've been there with connected components for everything, and I quickly went back. YMMV.

from react-reformed.

@davezuko Thank you for the thorough reply, it was exactly what I was hoping for. This all definitely makes sense and not having used redux-forms before I was not aware of the pitfalls that you mention (just a cursory glance at the v6 changelog is where i got my information, obviously not the best way to operate). I can imagine now why v5 had issues because of what you stated, the fact that all the reducers are triggered and checking for the proper action, and you're also correct in saying that with clever use of shouldComponentUpdate, even though reformed re-renders the form every time, the impact should be minimized (which it should be already anyway if you're writing your components properly).

All that being said, and I don't know if v5 is any different than v6, but I started to implement redux-form v6 in my app and without even doing anything I ran into a giant issue. If you're curious you can see the issue i opened against their repo. I had started my branch in my code off with reformed and it had no such issue and as such I think I'm going to opt for using your module versus redux-form.

Lastly, you are also correct in saying that it would be easier for me to rip this out than redux-form in the long run so again, you're right in everything you stated :) Redux is a fantastic piece of code but you can definitely hurt yourself very quickly if you are not 100% sure of what you're doing or take one misstep.

Thanks again for taking the time and for providing reformed for public consumption. I'm going to preemptively apologize for future me probably asking more questions down the line.

from react-reformed.

Glad that cleared things up, I was worried that the wall of text just bounced around rather than hitting on points succinctly.

Don't hesitate to post questions as issues, I'm used to it by now (though a gitter channel would probably be helpful). We're all still learning, so it's always better to throw ideas around and debate them than pursue them blindly. Thanks for taking the time to check out the project thoroughly enough to bring up your concerns!

Should have posted this in the original reply, but this has always been an interesting talk to me: https://www.youtube.com/watch?v=4anAwXYqLG8&feature=youtu.be&t=13m15s

from react-reformed.

Also: if you do find pain points with the concepts of reformed, please share them. At a minimum they could be incorporated into the README so people are aware of what to expect.

from react-reformed.