v3 Umbrella

[johnrom]

Dev Sprint

Full Milestone PR here: #3231

Original PR list for each feature:

1. PR Choose a state optimization method: useContextSelector v3 #2846, useSubscription Use FormikApi + FormikState Subscriptions #3089
2. PR Add parse/format to it: v3 #2846
3. PR Add useFieldArray to it: FieldArray over v3/reducer-refs jawnstreams/formik#22
4. PR Migrate useOptimizedSelector to npm package
5. PR Add micro-hooks from: v3 #2846
   • Rebase useIsValidatingHook
6. PR Separate FormikContext and FormikConfigContext: Add missing validationSchema to Formik context #2933 (comment)

Once all of the above are merged, I would consider tagging it rc1.

Probably needed for v3.0

• Add Explicit Return Types to API hooks Add Explicit Return Types to v3 #3144

Probably backlogged:

• Support innerRef + subscriptions (AddFormEffect): v3 w/ Subscriptions may need an effect hook to connect parent state via innerRef. #3141 (this wasn't supported before either)
  • Previously, the innerRef would pull the initial state, but it would never update after the initial mount.
• Optimize connect: Add optimization capabilities to connect #3110
• Explore Formik Plugins: Formik Plugins #3109
• Strongly Typed Formik, Fields, FieldArray: Strongly Typed Fields #1334

Administrative:

• Combine app/, examples/, and all code from documentation and tutorials.
• Deploy the same things to a single codesandbox as app/ during development, and use this as the learning codesandbox.
• Update docs, include code in docs directly from /app using something like: https://github.com/owickstrom/pandoc-include-code

[Tigge]

If these are breaking changes could you perhaps consider removing prepareDataForValidation as well? See #2047.

Perhaps the licensing issues could be taken care of as well. It is getting harder and harder to recover from that one... See #2735.

[johnrom]

A quick (lol not quick) recap of the purpose and benefits of this Umbrella set of changes which I am recommending for v3:

1. Exposes "future state"

You can access future state via getState() and render state via useState(). This is like Redux. It enables uses like:

<Formik
  onSubmit={async (values, api) => {
      const result = await checkApiThing();
      // make sure these form values aren't stale
      const stillRelevant = isEqual(values, api.getState().values);
        
      if (result.success && stillRelevant) {
        doImportantStuff(values);
      }
  }}
/>

2. Brings Optimization to the API level instead of Context level.

Bringing the subscription API inside of Formik instead of optimizing at the context level gives us some significant benefits.

Does not force users to use Context to receive optimizations.

Someone writing their own Form system could just pass the Formik API to a child component and useState() on it to get optimized subscriptions.

Enables optional subscriptions

<Field /> can be optimized, subscribing only to useFieldMeta, while <Field>{render => null}</Field> can subscribe to Formik's full state to make it available to the render function. This supports both rapid prototyping and optimization when necessary.

Puts all state updates in the same place.

Using useContextSelector, the dispatches to Formik would be triggered and useFormik parent component would receive the result of those dispatches immediately, but all child components would receive those updates after a Layout Effect. If the children take too long to render, it may be possible that those states could tear with the Parent State. The subscription PR above triggers all state updates at once in a single Layout Effect, and the parent accesses the same subscriptions via formik.useState().

This is probably mostly a concurrent mode issue. Not sure if Layout Effects in children are guaranteed to be run in the same render as the parent without a layout effect in legacy or blocking mode.

3. Adds other features which could have also been achieved with useContextSelector.

But they would only apply within Context and not outside of Context.

Enables Dynamic Slicing

The previous v3 PR didn't give devs a way to dynamically select a cross-section of state. We could do things like useField building known state out of micro-hooks, but that wouldn't support any dynamic selectors like:

<Field 
  type="number"
  name="width" 
  include={state => ({ height: state.values.height })} 
  validate={(value, { height }) => value * height > 100 
    ? "Max of 100 square feet."
    : ""
  }
/>

Does not force users to use micro-hooks to access Formik API.

In previous v3 PR, a user has to do things like useSetValues() in order to get parts of the formik API. With this PR, the API itself (FormikContext) is fully memoized, so a dev can just useFormikContext() and gain access to the full API.

[keremciu]

is there gonna be a v3 really?

[johnrom]

@keremciu whether my changes are ever merged into Formik itself isn't up to me, but my fork is available for test purposes here: https://www.npmjs.com/package/@johnrom/formik-v3

It has 1-6 above and Strongly Typed Fields #3152, though notably does not support passing "Extra Props" through the Field component. Due to lack of movement, I've only been focusing on the requirements I need to fill for my own projects.

Sandbox is here: https://codesandbox.io/s/serene-napier-4wjxs?file=/src/App.tsx

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 60 days

[dantman]

There is an alpha of React 18 out now, with full concurrent rendering. An implementation of useMutableSource is included, though not finalized and they are taking feedback from libraries during the alpha period.

This is probably a good time to try using useMutableSource in place of useSubscription.

[johnrom]

I'm definitely down for that. I think since in my testing the API could remain the same I would recommend going with this branch first, then falling forward to useMutableSource via some sort of opt-in mechanism. I have no idea what that mechanism would look like without breaking backwards compatibility while fixing the issues people using React@<18 are currently having with Formik.

Ideas have been:

• a webpack plugin that can do some aliasing
• maintaining separate branches / packages of Formik
• etc

[johnrom]

Created an Umbrella issue for tracking Concurrent Mode items #3236

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 60 days

[dantman]

Not stale

[dantman]

Formik is in major need of a v3. It's been nearly a year since the key improvements to Formik were written and we're still stuck between v2 with it's major issues and 2 "not even alpha, do not use" releases.

1. Major performance issues unless you rewrite things to use FastField instead of useField.
2. Bad TypeScript types.
3. Lack of parse/format placing strong limitations on the structure that values can have requiring lots of conversion back and forth in initialValues and submit.

It would honestly be better to have a v3 for React 17 now even if it has tearing issues if you use concurrent features in React 18@alpha. And a future v3.1/v4 release with useMutableSource to fix tearing issues and pave the way for React 18.

What work (besides approval from @jaredpalmer) is needed to complete #3231?

[Tigge]

From what I can see he doesn't really seem to be involved much here anymore. Might be time to fork the project so it can continue to be useful.

[johnrom]

#3231 is complete as far as I can tell and needs only some secondary eyes on it before release. I'm using it in development already and it's working great.

I use both refs3 and types12 here, though idk if I'd release the strongly typed version as it's not feature complete and might need an entire rewrite if typescript adds features supporting an alternate method.

Types12 is the PR strongly Typed Formik or something btw

[dantman]

I'm fine without the strongly typed version. By bad TypeScript types I was actually referring to how v2 has absolutely awful TypeScript mistakes like GenericFieldHTMLAttributes being part of useField's config even though it doesn't use them. So I regularly have to use as any to stop TypeScript from generating completely incorrect TypeScript errors when using parts of Formik v2. This was already fixed long ago in v3, but no production release with it has ever been released.

I'd happily use the alpha, give it some more eyes, and fix anything I find that's in my way. Though I think we're going into production in a couple of months.

[ZipBrandon]

I've been tracking v3 for quite some time. I appreciate your heroic efforts on this @johnrom. I would love to transition from v2 to v3 but the only reservation I have is documentation or examples of the v3 of using Formik. Once I have that understanding then I'll eagerly utilize in production. Is there any current state (or expected date) of documentation or tutorials that can be used for reference?

[johnrom]

@ZipBrandon definitely not using it in production just yet, but hoping for some documentation in the next two weeks.

For simple examples using the Formik components (Formik, Form, Fields), nothing has changed. However, using the useFormik hook and innerRef has changed since neither of these will return state.

[onuralpbicer]

Are there any plans for production ready release of a v3? I'd be happy to help with documentation or examples or code.

[dantman]

Is @jaredpalmer going to merge anything into a new official alpha. Or @johnrom are you interested in forking Formik or having your current fork used in production?

I'm willing to contribute. Use the alpha, report and make PRs for any bugs I encounter. Maybe update the documentation a little (though I'm not that capable at writing documentation). etc

But I've been waiting for v3 for, *checks git*, 9 months. And I'm now on the verge of needing to either upgrade to formik v3 (in an application currently in the internal usage phase before production); or rewrite our form handling code to use a different library.

[johnrom]

I'm using my fork internally without issue and it's fantastic. I'd love to fork it and create an actual governance model around the fork that I wrote, but I haven't seen much interest in actually using my fork or testing it, and it would be a huge investment of time and resources. It would also be better to get the author's buy-in or ideally create a governance model in-place around the current project.

I know Jared has used my fork and said that it works well, but other than that I haven't gotten any feedback -- especially from the React Native community. I really don't know if my Fork works for RN users except with the very specific test environment I used.

[ZipBrandon]

I'm saddened by the stall of v3. I have used formik since 2017. I had been thinking v3 was right around the corner since March and kept hanging onto hope. I really needed it to stabilize re-renders in my app, majorly due to extensive use of helpers in useField(). I ended up biting the bullet a few months back and converting everything over to react-hook-form throughout our B2B app. I appreciate everything @johnrom did to move formik forward. It's a regret that there were other obstacles in the way. I wouldn't be surprised if real life events have taken priority and focus from @jaredpalmer. I entirely understand. I'm just a user and not a paying sponsor so I accept I am getting what I pay for. I don't manage any FOSS project because I don't want to nor have time to handle the commitment. I hope formik continues.

[msageryd]

I read about V3 and got excited. If I understand correctly, there might not even be a V3?

OSS is a hard place to navigate. I'm leaning more and more towards paying a fee to ensure the ongoing investment in the software I use. All OSS maintainers are heroes, but we probably need a better model for this to work in the long run.

The reason I'm here is that I'm suspecting that my current form-lib, Final-Form, has lost it's momentum. I'm so far very happy with Final-Form, but I'm worried of what might happen in the future. I'm mostly on React-Native, and 2022 will probably be the year when we get to see the shiny new version with synchronous communication with the Native side. This is exciting, but I fear that this will reak havoc on component libraries. Actively maintained libs will mitigate this risk.

As of now there seems to be no incentive for me to rewrite from Final-Form to Formik, since Formik seems to have lost momentum as well. But if V3 would get traction, docs, maintainers, etc, I would gladly give it a serious look. I'm quite deeply invested into Final-Form, so the rewrite wouldn't be a quick-fix.

@johnrom I'm cheering for you. You are one of the heroes I wrote about above. I'll follow this thread with interest.

[adam-thomas-privitar]

I feel like at this point, a "proper" fork (maybe "formik-continued" or "formik-enhanced" or something) is the way to go. I suspect theres more interest than it looks if you only consider this thread. But, I think that would only become apparent once it first breaks ground.

[douglasjunior]

As of now there seems to be no incentive for me to rewrite from Final-Form to Formik, since Formik seems to have lost momentum as well. But if V3 would get traction, docs, maintainers, etc, I would gladly give it a serious look. I'm quite deeply invested into Final-Form, so the rewrite wouldn't be a quick-fix.

Rewrite projects from FinalForm to Formik is a downgrade in my opinion, I always prefer FinalForm because it's more powerful (format, parse, validate, array), customizable and works truly independently of the platform (Web or Native).

Although Formik reinforces that it's 100% compatible with React Native, this is not true, which is why I am here. We can't use <Field/> or useField with React Native without workarounds, because things like onBlur and onChange strongly depends on browser events.

I'm also available to collaborate on anything that is necessary, I have good experience with forms and inputs of various types.

[msageryd]

@douglasjunior As I still was worried about the maintenance of FF, so I have migrated evrything to react-hook-form
https://react-hook-form.com/. This went very well. I ended up with the same functionality, probably better performance and less code.

[tyteen4a03]

I really don't like the semantics of having to register() everything so I hope Formik gets more love.

It seems unfortunate that @jaredpalmer has abandoned the project. Please do release a fork @johnrom !

[stefanmaric]

It seems unfortunate that @jaredpalmer has abandoned the project.

Formik promised us "forms in React, without the tears", and yet, find us all here crying our hearts out awaiting for @jaredpalmer's comeback. 😭

PD: just joking

[johnrom]

Hi all, please stop tagging people on public repositories, it's rude. Nobody promised anything, liabilities, open source, etc etc. People have lives and sometimes they move on. Just adding some emojis to the PR is a good enough signal of your interest in the PR without being disruptive. Please keep comments related to issues which arise from your testing of the PR I linked to or additional considerations I haven't written in the issue itself.