Fix: Introduce useFastField React hook

[sparkboom]

This PR offers an implementation of useFastField React hook as a solution for issue #1026 and #671 for Formik's 'next' release. It behaves like a FastField where the state of the field does not update Formik's values and errors model until the user's focus is removed from it providing some optimised behaviour.

Included in this PR is

1. Suggested document additions for the useFastField hook
2. Simple hook implementation.

---

View rendered docs/api/useFastField.md

[johnrom]

I wonder if it would be useful to skip the optimization when there is an error, so that the error can be resolved as soon as possible. (A user might think they still haven't fixed the value until the error goes away)

[jaredpalmer]

@johnrom can you share some pseudo-code for how that might work?

[johnrom]

I might be way overthinking this but:

field.onChange = React.useCallback(
    meta.error 
        // if there's an error, just call onChange
        ? onChange
        // am I delusional? do we need to support onChange('string', value) ??
        : (
            eventOrPath: string | React.ChangeEvent<any>
        ): void | ((eventOrTextValue: string | React.ChangeEvent<any>) => void) => {
            if (isString(eventOrPath)) {
                return event => setValue(event.target.value);
            } else {
                setValue(eventOrPath.target.value);
            }
        },
    [meta.error]
);

[wellyal]

@sparkboom nice!! I have a scenario where I have to use a custom onChange function. Wouldn't be nice if the useFastField also received a custom onChange function as a parameter?

[3nvi]

While this approach is not bad, I personally think that it doesn't help when you want to react to something as you are typing (before you blur).

I think that Formik might need to combat the underlying issue that every Field component gets updated on every values update, regardless of whether it needed to update or not (related issue #1804)

While useFastField could work in some cases, I'm not fully sure if it's a solution...

[jaredpalmer]

@3nvi I think we'll be able to tackle this in v3 with React Flare

[3nvi]

@3nvi I think we'll be able to tackle this in v3 with React Flare

That's great! Is there an (unofficial & non-bounding) estimation on that?

[maxijonson]

I noticed, in the PR's suggested useFastField, that the type of props is FieldAttributes<Val> instead of string | FieldHookConfig<Val> (type of propsOrFieldName for useField). Is there any reason for that? Also, is there a reason why helpers is not returned like useField?

[johnrom]

@jaredpalmer just came across your note here and it looks like Flare has been abandoned:

We're not longer working on this particular approach and will be exploring other ways to work with the DOM event system in the future. We've concluded that the "Flare" event system is too high-level an abstraction and we'd like to explore something that is a bit more familiar to developers familiar with the DOM (e.g., addEventListener) and React's existing tools (e.g., hooks). Our goal is still to make it possible for library authors to work with passive events, capture/bubble phase, custom events, and events occurring on the document from within a React function component...while reducing the amount of event-related code needed in ReactDOM. Ultimately building both intermediate abstractions like the Responder Event system and high-level abstractions like useTap (which we prototyped in Flare) should be possible in user-space.

facebook/react#15257

[jaredpalmer]

Good look. Just subscribed. Will follow up with React team directly about next steps

…

-- Jared

________________________________ From: John Rom <[email protected]> Sent: Wednesday, January 8, 2020 12:05 PM To: jaredpalmer/formik Cc: Jared Palmer; Mention Subject: Re: [jaredpalmer/formik] Fix: Introduce useFastField React hook (#1772) @jaredpalmer<https://github.com/jaredpalmer> just came across your note here and it looks like Flare has been abandoned: We're not longer working on this particular approach and will be exploring other ways to work with the DOM event system in the future. We've concluded that the "Flare" event system is too high-level an abstraction and we'd like to explore something that is a bit more familiar to developers familiar with the DOM (e.g., addEventListener) and React's existing tools (e.g., hooks). Our goal is still to make it possible for library authors to work with passive events, capture/bubble phase, custom events, and events occurring on the document from within a React function component...while reducing the amount of event-related code needed in ReactDOM. Ultimately building both intermediate abstractions like the Responder Event system and high-level abstractions like useTap (which we prototyped in Flare) should be possible in user-space. facebook/react#15257<facebook/react#15257> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1772?email_source=notifications&email_token=AA67IG37HPAQEXLJBYQ4A3DQ4YWXVA5CNFSM4IPH2Z22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEINZTVA#issuecomment-572234196>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA67IGZF7O6IOQSW4HQEEMDQ4YWXVANCNFSM4IPH2Z2Q>.

[chriskn]

Hi, @jaredpalmer are there any plans to provide a useFastField hook? The slow performance, specially in IE is a showstopper for me.

[thadeu]

@sparkboom missing helpers right?

[sibelius]

can we release this as experimental?

[Dashue]

Another guy here that could benefit from this

[Its-Alex]

Up?

[sibelius]

you can copy and paste from here https://gist.github.com/sibelius/ccea4d505eb20d0dd08c19716c469093

until this lands

[gperez-10pines]

Looks like approved but somebody is not yet pressing the button?

[johnrom]

@gperez-10pines not at all. None of the solutions are ideal, the performance with Field itself needs to be fixed. FastField was a meh solution in v1. You're free to try various userland solutions, but I don't think Formik will adopt anything until we figure out a real highly optimized method using #2749 or something else.

I believe the React team has focused on "abandoning renders" when nothing really changes instead of preventing renders from starting, so has not been focused on optimizing Context which Formik is using and is causing this performance issue. At least that's my impression of the state of things.

[jaredpalmer]

This is correct. However, I'm working on fixing field. Fastfield was a hack for v1 that has no parallel in hooks land. shouldComponentUpdate is different that the implementation here. My progress on fixing this can be seen here #2749

[jaredpalmer]

This has been implemented in v3 with just the regular useField. Closing.

[ortonomy]

sorry to dig this up, but @jaredpalmer -- I can't see any reference to a fast boolean or anything else about how this is implemented in regular useField in the docs: https://formik.org/docs/api/useField

Is this just built in behaviour for the hook?

[honia19]

sorry to dig this up, but @jaredpalmer -- I can't see any reference to a fast boolean or anything else about how this is implemented in regular useField in the docs: https://formik.org/docs/api/useField

Is this just built in behaviour for the hook?

Formik died.