Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formik performance enhancements #2221

Open
wallymathieu opened this issue Jan 17, 2020 · 1 comment
Open

Formik performance enhancements #2221

wallymathieu opened this issue Jan 17, 2020 · 1 comment
Labels

Comments

@wallymathieu
Copy link
Contributor

wallymathieu commented Jan 17, 2020

馃殌 Feature request

Current Behavior

The current behavior is to send relatively large chunks of information to the reducer.

For instance when dealing with an array of values the change is sent for the entire array. HandleChange computes change when it instead it could be sent to the reducer.

Dispatch and state is in the same context.

Desired Behavior

The desired behavior is to send "smaller" messages in order to let the reducer do the work.

Having dispatch and state in the same React context can if we believe this post impact performance.

Suggested Solution

Send messages such as :

  • 'ARRAY_PUSH'
  • 'ARRAY_SWAP'
  • 'ARRAY_MOVE'
  • 'ARRAY_INSERT'
  • 'ARRAY_REPLACE'
  • 'ARRAY_UNSHIFT'
  • 'ARRAY_REMOVE'
  • 'CHECKBOX_FLIP'

That way ArrayHelpers could contain less state.

Split Formik React context into two parts.

Who does this impact? Who is this for?

People who have very large forms using FieldArray. Removing return values from array helpers could change the API slightly. In order to avoid having an impact on people using specific parts of the FieldArray API you could have an alternate version with a slightly different API and a new name.

Describe alternatives you've considered

Using a fork of Formik without regard for backwards compatibility (that can be used alongside Formik):
https://github.com/wallymathieu/formik-reimagined

Additional context

@wallymathieu
Copy link
Contributor Author

Perhaps this should be closed, since the perf is good enough for many implementations? @jaredpalmer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant