Use FormikApi + FormikState Subscriptions #3089

johnrom · 2021-03-11T22:26:01Z

This pivots Formik away from using Context for anything but the API itself, and exposes a formik.useState() implementation to subscribe to Formik State via a selector and comparer when you need to do specialized equality checks. Implemented with use-subscription.

Upgraded Dev Environment

The new Development environment is awesome. Try it out. VS Code will now run your tests automatically with the Jest extension. Running npm run start:app, or just Launching from VS Code, will now run the app/ folder aliased directly to Formik's source at localhost:3000, so you can test and develop Formik directly through /App. You can also launch Chrome against it to attach breakpoints to Formik.

Added Ref State. Added useSelectorComparer. Starting to build subscriptions.

…ohnrom/subscriber

use-subscriptions might not work in React 17? Seems returning the previous value doesn't bail out the render.

Sync up formik-native and formik for v3.

changeset-bot · 2021-03-11T22:26:03Z

🦋 Changeset detected

Latest commit: f3bd303

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
formik-native	Major
formik	Major
app	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

vercel · 2021-03-11T22:26:05Z

@johnrom is attempting to deploy a commit to the Formium Team on Vercel.

A member of the Team first needs to authorize it.

jaredpalmer · 2021-03-15T19:35:44Z

packages/formik/src/hooks/useFormikComputedState.ts

+  initialValues: state.initialValues,
+});
+
+export const useFormikApiComputedState = <Values = any>(formikApi: FormikApi<Values>) => {


consider removing? or replacing with just useIsValid useIsDirty

I moved computed state to api.useComputedState() so it is accessible from anywhere, and only expose the hooks useIsValid and useIsDirty.

jaredpalmer · 2021-03-15T19:36:40Z

packages/formik/src/hooks/useFullFormikState.ts

+
+export const selectFullState = <T>(value: T) => value;
+
+export const useFullFormikState = <Values>(


full, computed, api, state, selectFull, need to reduce the surface area.

useFormikApi is needed, as it gets the Context, which is now only the API

useFormikState is an alias to (selector, comparer) => useFormikApi().useState(selector, comparer), which seemed a little tedious to make users use. However, we have to expose that for any of this to work, so it's up to you whether we keep this hook or make users use useFormikApi().useState()

useFormikApiState(api, ...etc) can probably go, since it is just api.useState(selector, comparer);

selectFullState is not something we should expose, it's just something we use internally instead of memoizing a new selector. I can go through and mark stuff like this @internal.

useFullFormikState is used by backwards compatible useFormikContext which users expect to load the legacy "formikBag". It's also used internally to subscribe to the full state in the case of Formik and Field render / child fns which do not have access to hooks to get Formik's state. it doesn't need to be exposed -- I can mark it @internal

Can useFormikState become useFormikStateSelector() or just useFormikSelector()?

I would also like to suggest changing useFormikApi() to useFormikActions() or useFormikMethods(). Mentally, easier to think about state or actions/methods versus state or api I think. api could be anything and it isn’t clear whether or it holds state.

Edit: I now see that these mean different things and my prior comment is wrong.

I still think API is a meaningless word and would like to see it changed. useFormikApiState vs. useFormikApi vs. useFormik vs. useFormikState isn’t intuitive for end users.

Formik API is the only word here that makes sense to me.

A getter is not an action

A method is a function belonging to an object in OOP, which isn't really applicable to functional programming like Formik whereas it might apply more in other form APIs since they use classes under the hood.

The type returned by useFormik is FormikApi and the type exposed by Context is also FormikApi, so useFormikApi seems to be the best naming convention for the context since we can't use useFormikContext.

If you do not believe that useFormik returns an API, that is a whole different story. I don't think it returns Methods, or Actions. Maybe Helpers?? But we already draw a distinction in TypeScript between Helpers, Handlers, and Config.

Let's decide what the TypeScript name for the return value of useFormik is, and we'll change the name of useFormikApi to match. Whatever it is, the Context holds that value so the names should match.

I think it'll be super clear that "API" is the right word for the API that Formik provides if we document it separately from the various components and hooks that we provide, and separately from the State.

A person who simply uses useFormik() and builds everything else from scratch is only using the Formik API, and we should document that separately. The current documentation uses API Reference to mean "all the things" whereas the API Formik provides is just what is returned by useFormik and every other component or hook we provide is a shortcut for using that API.

We can always break backwards compatibility and switch useFormikContext to just have the API, and then it'll be useFormikContext and useFormikState.

I did the above, switched back to useFormikContext and useFormikState, abandoning backwards compatibility for clarity.

jaredpalmer · 2021-03-15T19:37:02Z

packages/formik/test/withFormik.test.tsx

@@ -103,6 +103,7 @@ describe('withFormik()', () => {
      setSubmitting: expect.any(Function),
      setTouched: expect.any(Function),
      setValues: expect.any(Function),
+      isFormValid: expect.any(Function),


isFormValid is a function passed by Formik API which is needed to calculate whether the form is valid. Otherwise, we need to pass a bunch of config props from Formik through the API, and if a user doesn't memoize them we lose all of the performance gains.

Removed isFormValid in favor of exposing formikApi.useComputedState().

johnrom · 2021-03-17T14:47:58Z

This currently passes the following props through the API which I think we should remove, because they are likely to cause re-renders if a user doesn't optimize them.

{
  validationSchema?: any | (() => any);
  validate?: (values: Values) => void | object | ValidateFn<Values>;
}

…seIsValid

…te will do. If we call our own reducer then use useReducer dispatch, `state.values !== getState().values`.

johnrom · 2021-03-18T15:35:47Z

I found a small issue with this method. If we dispatch two values in a row, it's theoretically possible to skip a dispatch using use-subscription because it comes directly from getState() instead of state. This is fine for the render because it'll always become consistent with the latest info, but it's not OK if a dev needed two discrete effects to be triggered. This didn't happen in my original subscription implementation. I'll write a test for this scenario.

~~Proposed solution is to add a useEventCallback version of getState which can get the state snapshot returned from React.useState(), and use that in the selector for use-subscription.~~

Ignore the above, as this is just how batching works in React. I've been thinking about this for too long. 😂

I'm going to start adding some of the app/ code from #2846 and #2931 over the next week and do some more testing as well.

…ormikReducerState + FormikComputedState. Add Fixtures and Tutorial code to /app.

Consolidate State and Add Tutorial + Fixtures.

johnrom · 2021-03-22T22:12:52Z

I figured out how to remove useComputedState entirely. Now useState() will return FormikState, which is FormikReducerState + FormikComputedState, simplifying the API dramatically.

johnrom · 2021-03-23T20:00:42Z

@jaredpalmer this is ready for review and I believe I've resolved all the items above. I did the following:

removed all State from FormikContext and switched back to calling it FormikContext instead of FormikApi
combined computed state into api.useState / useFormikState, removing all the confusion around computed vs reducer state
removed isFormValid function as isValid is computed during getState()

You can test the branch locally by pulling the branch in VS Code, running yarn to link the workspaces, and running the run npm dev task. It will boot up /app folder connected directly to /packages/formik/src.

jaredpalmer

Almost there...

jaredpalmer · 2021-04-10T14:39:54Z