search

jaredpalmer / formik

Build forms in React, without the tears 😭
https://formik.org
Apache License 2.0
33.87k stars 2.78k forks source link

v3 Umbrella #3099

Open johnrom opened 3 years ago

johnrom commented 3 years ago

Dev Sprint

Full Milestone PR here: #3231

Original PR list for each feature:

  1. PR Choose a state optimization method: useContextSelector #2846, useSubscription #3089
  2. PR Add parse/format to it: #2846
  3. PR Add useFieldArray to it: https://github.com/jawnstreams/formik/pull/22
  4. PR Migrate useOptimizedSelector to npm package
  5. PR Add micro-hooks from: #2846
  6. PR Separate FormikContext and FormikConfigContext: https://github.com/formium/formik/pull/2933#issuecomment-804314085

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

Probably needed for v3.0

Probably backlogged:

Administrative:

Tigge commented 3 years ago

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 commented 3 years ago

@Tigge depending on whether the Formik Plugin API is adopted and we move Yup there, #3109 would probably be the time we examine prepareDataForValidation.

I'm definitely not involved with the licensing stuff and it seems that would be addressed independently of any features which fall under this umbrella. Insofar as I am aware, MIT license does not enforce MIT license upon derivative works. (Future Formik versions may be interpreted as a derivative work of its previous versions, though I am not a lawyer in this regard. I'd imagine in that case the "Source Work" would require a callout to the MIT license, which could be something to consider.) This was a huge problem for GPL projects as GPL required derivative works to be GPL, and thus relicensing required every contributor's approval. I am not expressing agreement with the change itself, but simply wanted to share that while it is an odd move on Formium's part (I am not involved there), it's not necessarily without precedent (though I am not a lawyer). I believe the reason React didn't switch to Apache licensing wasn't because there needed to be contributor buy-in, but because huge stakeholders like WordPress expressed concern and considered moving to other frameworks. I'm sure if there are a large percentage of stakeholders here that are affected they will come forward and drive the conversation further. I would keep that discourse on the other issue though, as it's independent of this feature set.

Tigge commented 3 years ago

@johnrom sounds good!

Here is my understanding of the licensing situation (also not a lawyer):

The MIT license does enforce some clear requirements. They require that:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

If this is fulfilled, there is no real problem as such. The project would then consist of old MIT code (which should contain a copyright notice) from before the "license switch", but that code needs to be marked as MIT with a copyright notice.

The new code can then be licensed under the Apache license. Files containing both MIT-licensed code and Apache-licensed code need to be marked as such as well. Both Formik and projects using it, or code from it, would need to include both licenses to be compliant.

The other solution would be, as you say, to get permission from all contributors to release the code under the Apache license and have the code only licensed under Apache. Personally, I would not object to that.

Having the package.json files specifying that it is licensed under MIT might give some small ambiguity as to what new code is licensed under, which could be rather troublesome, but I'm guessing that new code would be found to be licensed under the Apache license. The package.json license fields should be MIT AND Apache-2.0.

So, in short, as it is now, Formik is currently infringing on copyrighted material. It does not fulfill the license conditions:

  1. The MIT code is not marked with a copyright notice
  2. Licenses are not included
    1. No MIT license in the git repository (only Apache)
    2. Neither licenses are included in the NPM packages (also, the license field of the package.json is wrong, which could be a violation itself, but I'm not sure about that)

Many users or customers who use Formik might also be infringing since often license information is gathered automatically from the package.json file or the LICENSE file in the source code.

It is probably wise to sort this out as soon as possible before anyone gets sued or a DMCA takedown happens...

johnrom commented 3 years ago

As mentioned before, this isn't the relevant issue and I'm not involved in the matter, so I have no comment on your response above. I personally would rather that discussion took place on the relevant issue and not here.

johnrom commented 3 years ago

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 commented 3 years ago

is there gonna be a v3 really?

johnrom commented 3 years ago

@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[bot] commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

johnrom commented 3 years ago

Created an Umbrella issue for tracking Concurrent Mode items #3236

github-actions[bot] commented 3 years ago

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 commented 3 years ago

Not stale

dantman commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 2 years ago

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

dantman commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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. :sob:

PD: just joking

johnrom commented 2 years ago

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.