[UXPROD-1990] Migrate to React Final Form Created: 21/Jan/19 Updated: 01/Mar/21 Resolved: 13/Nov/19 |
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | New Feature | Priority: | P3 |
| Reporter: | Khalilah Gambrell | Assignee: | Khalilah Gambrell |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | NFR, tech-debt, ux | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||
| Front End Estimator: | Ryan Berger | ||||||||||||||||||||||||||||||||||||
| Development Team: | Stripes Force | ||||||||||||||||||||||||||||||||||||
| Description |
PurposeEarly in the FOLIO project, we made the decision to use Redux Form to help construct forms with complex state. Redux Form has been a huge time-saver, since we don't have to roll a new state machine ourselves every time we build a new form. In the years since we adopted it, the thinking around form state in the React/Redux community has evolved. The Redux docs even indicate tools like Redux Form probably aren't needed: https://redux.js.org/faq/organizing-state#should-i-put-form-state-or-other-ui-state-in-my-store Final Form is the direct successor to Redux Form. Final Form has significant performance gains because it doesn't dispatch actions to the Redux store on every key press. It doesn't even use Redux. Additional benefits of Final Form we'd immediately benefit from:
ApproachEncourage the use of React Final Form instead of Redux Form. ui-eholdings is already migrated over: https://github.com/folio-org/ui-eholdings/pull/680. Besides the performance benefits, I've much preferred the ergonomics of using React components instead of reduxForm() calls scattered around the component tree (which are really wrappers for redux connects). With Redux Form, it was much more difficult to adhere to one of the tenets of the route-based architecture defined in STRIPES-589: Only route components found in src/routes communicate with the data layer or server. There are cases where Redux Form is still the appropriate tool, like multi-page wizard forms, but they won't be the norm in FOLIO. We should remove the redux-form reducer from stripes-core, but modules that want to use redux-form for exceptional cases can still add that reducer themselves. ui-eholdings has an example of injecting a reducer. In a post-Redux Form stripes ecosystem, the stripes-form library is no longer necessary. stripes-form provides two key pieces of functionality:
TasksTier OneThese are the items needed to unblock anyone from using React Final Form with the same features currently available from stripes-form.
Tier TwoThese are the next steps, where stripes-core and stripes-smart-components would no longer depend on stripes-form. Can be done in parallel with Tier Three tasks.
Tier ThreeMigrating modules will take a while, but can be done on any timetable. At this stage redux-form and react-final-form can continue to be first-class citizens together.
SomedayThis is the stage where redux-form first-class support goes away, and modules that want to use it would need to add the reducer themselves.
ReferencesErik Rasmussen — Final Form: Form state management via Observers |
| Comments |
| Comment by Khalilah Gambrell [ 22/Jan/19 ] |
|
Jeffrey Cherewaty and John Coburn - should this be considered a RFC? |
| Comment by Khalilah Gambrell [ 13/Nov/19 ] |
|
Closing feature. Will provide a React Final Form migration guide |