v3 RFC discussion

[johnrom]

Let this serve as the first real test of Github Discussions as pertains to Formik. Continuing off of the PR, I think we should create an RFC for v3 that contains an API which is agreed upon (by who?) in some way before creating, or based upon implementations in, MVP PRs like the aforementioned v3 MVP PR.

I've been seeing a lot of issues lately where users are left without options (or using sub-par options) when pursuing certain functionality, and I think a part of continuing to support such a large community will be making sure the v3 API can support these various use cases (as well as what we currently support). I found that many use cases would be supported by allowing the Reducer that Formik uses to manage state be replaced or enhanced by a user, and I will probably try and create a PR based around this concept.

The overall first priority of v3, however, will be performance. It seems that React Context has put us in the same situation as many who have come before us -- performance has tanked since implementing it because it is very hard to memoize the rendering of components based on the slice of context that they require. We are basically Redux v6 right now, and it is clear that users have noticed.

In the MVP PR, there was an attempt to circumvent this performance issue by managing state at the Field level. I think we need to benchmark whether this actually improves performance overall, or if it trades context performance for making it prohibitively expensive to manage state at the form level. I don't have an answer to this, but I'd guess that managing dependent field values would be super expensive in the v3 MVP, which for my use cases would be a huge step back.

I think we need to execute this initial performance trade-off just right in order to remain competitive with other form libraries. I was hoping we'd have some kind of Context Selector API in React by now which would solve this problem. There are hints of some experimentation with useMutableSource and "another system" which sometime in the future may allow us to use performant Context-like state at the Form level. I think there is a case for managing more state at the Field level. But I think the core of Formik is still Form-level, and users are going to want configuration and performance optimized at that level and the Field level. Therefore, I think this RFC should outline which state is managed at the Field level and which is at the Form Level.

I think the RFC should also outline and provide the necessary escape hatches to get state bound to a specific render vs. future state accessible from callbacks, events and effects. I feel like the current API is a bit muddy in this area (or maybe just the documentation is?).

For an RFC, I'd like to gather some of the impossible or non-ideal workarounds we have currently in the issues and gather them here for discussion for inclusion into the RFC, and create a set of requirements that would form the basis for Formik v3 RFC which includes support for those scenarios, a very explicit and concise API definition, and a baseline of Form- and Field-level performance we'd want to achieve before shipping (how can we quantify that?).

Let me know what you think about this plan of attack!

RFC Requirements

• Collect currently Impossible features / non-ideal workarounds required by the current API.
• Define an Explicit and Concise API Definition including current Render State and "Future" State (refs).
• Determine baseline Form- and Field- level performance metrics for comparison to prove any new API fixes our performance concerns / detect performance regressions in future commits?? Wonder how other libraries solve this. Can we collect scenarios from the community?
• Collect any other requirements we want for v3.

Impossible features / non-ideal workarounds

• No onChange prop for <Formik/>? #1633 Form onChange (non-ideal)
  • using Effects for onChange is not always ideal because an additional component is necessary and the callback only happens on the next render, and the callback could cause another render (and another, and another). Using an enhanced reducer would allow a user to react to changes within the same render.
• RFC: Formik 3 #2360 (comment) Abstract over Formik's relationship to Yup

[jaredpalmer]

Agree. With all this. useMutableSource may be the only way out. We need some kind of benchmark so we can develop against it. Perhaps cypress or puppeteer can help there.

Some more context on my progress...

• I have been anxiously tracking React Flare in hopes that Formik would take advantage the new event system. However, it is stalled at the moment. Instead, Nicolas is working on some interesting experiments in userland with the React Native Web rewrite. My guess is that it is informed from the new fb dot com. Notably, the new RNW has a new event hook that uses browser events and refs. You use it on leaf nodes to assign listeners.

• I am using v3 RFC on upcoming features of Formik Cloud and actively incubating it. It works especially well on large multi-page survey forms. There are def optimizations that could be made that would improve perf on dependent fields by moving to useMutableSource and keeping a smarter registry of listeners.

• I am interested in playing with Recoil in the next few days. I’m curious to see if I like the api. If so, it may be a great inspiration for sharable and composable form state atoms. Perhaps even better than the state reducer we have already prototyped, would be a set of form atoms and selectors. The example I have in my head is form warnings (and maybe even all validation). Seems worth exploring.

[sakulstra]

Collect currently Impossible features / non-ideal workarounds required by the current API.

I haven't been using formik for a long time - didn't miss any features yet.
I relatively quickly ran into non-ideal workarounds though, to resolve the slowly creeping form lag with increasing form sizes.
A lot of the workarounds I found in the issues are related to bailing out of renders. If it's extensively using FastFields(or custom shouldComponent) or splitting up forms in smaller forms - as I get the points above none of that would longer be needed as soon as there's some kind of context-selector?

Determine baseline Form- and Field- level performance metrics for comparison to prove any new API fixes our performance concerns / detect performance regressions in future commits?

Was looking a bit in how-to measure react performance in a ci and stepped over react-hook-form vs formik which i think is a kinda unfair comparison, but symbolizes a bit of the problems I initially had with formik. You have to put quite some effort into optimizing things as they aren't by default.

Material-ui is benchmarking it's styling solution. Not sure if that might suite as inspiration? - i guess it's a lot harder to measure performance implications of state updates than simply measuring the mount time.

[johnrom]

Yeah, a lot of our performance concerns come between setFieldValue('myField', 'value') and waitFor(() => expect(domElement.value).toEqual('value');.

I wonder if we can write some tests that expect renders to happen x number of times in certain scenarios, which would reign in some of the more esoteric rendering issues we have. Might be able to use the example here: testing-library/react-hooks-testing-library#136

[jaredpalmer]

2020 Summer Update: Going to pause the existing v3 rewrite and replace with this Roadmap:

• Start to remove async validation with warnings
• Fix onChange to be more ergonomic and intelligent about events (breaking)
  • Deprecate field helpers with warning
• Strong typing w/ TS 4
• Document useFormik + <FormikProvider {...formik}> see (RFC: Make Form the context provider #2746)
• Fix Field component api mismatches (breaking, not able to warn)
• Get rid of innerRef usage and instead use forwardRefWithAs
• Consider splitting out withFormik into its own package?
• Get rid of lodash/path in favor of lighter weight solution. Once we pick out a new path library (if it's incompatible), we will sniff the name for [ and show deprecation warning.

[HiranmayaGundu]

@jaredpalmer If async validation is removed, would there be a way to call the server to check for validation errors? For example, we may want to check if the username is available before the user even submits the form.

[waynebloss]

@jaredpalmer Perhaps object-path-immutable can replace lodash/path.

[Mikoz93]

@HiranmayaGundu This should be fairly trivial to do when using the useFormik hook, as all the values would be available within the whole component scope. Then it would be a matter of checking for changes to the username from within a hook.