RFC: Improving Field

[jaredpalmer]

I want to take folk's temperature on some warts that I want to change related to <Field> as well as discuss how best to move forward in a way that doesn't force people to rewrite stuff immediately.

<Field component>

This prop is the source of a ton of confusion because it does not simply pass through onChange, onBlur, and value but rather field and form. This means that there is some inconsistent behavior with respect to <Field component="select"> vs. <Field component={MyInput}>. I think a decent solution is to create a new prop called is or as and make that prop just pass through onBlur, onChange, value/checked as expected. We then would put a deprecation warning on component instructing people to use as/is or children and eventually remove component entirely in future versions. Unfortunately, this will force folks to change every single "select" and "textarea" over time, but this at least avoids breaking changes

<Field render>

This is just redundant at this point. We should put up a deprecation warning suggesting to use children as a function.

<Field children>

We should merge #343 and add a meta to <Field children>.

<Field>
-  {({field, form }) => ... }
+  {({field, form, meta }) => ... }
</Field>

Next Steps

In a perfect world, we make these changes gradually in a way that prevents people from having to rewrite stuff. I definitely don't want to have to rewrite all my inputs, but we need to make these changes at some point. We also need to consider that <Field> will have a dramatically reduced usage in the future once the useField hook is released.

Umbrella Issues

• Field meta (Add meta prop to Field, FastField #343)
• Deprecate render and component (Create <Field as> and deprecate <Field component> and <Field render> #1406)

[VincentLanglet]

I agree passing onChange, onBlur, value and name directly instead of inside a field props is less confusing. It will be similar to component given as string and add more compatibility with other component, like Material-ui. Actually we have to do:

<Field name="email" type="text" component={(props) => <TextField {...props.field} {...props} />} />

But, it's not clear for me.
Do you still consider passing the form props or not ? I think this one can still be useful.

[WickyNilliams]

Sounds good to me. Would be simpler (or unnecessary) to adapt existing components to Formik

[Andreyco]

@VincentLanglet

But, it's not clear for me.
Do you still consider passing the form props or not ? I think this one can still be useful.

Based on original post it is most likely a NO. onChange, onBlur and value props only. Passing form is redundant.

[jaredpalmer]

Correct

[VincentLanglet]

I found useful to have access to form.touched[field.name] && form.errors[field.name]

[Andreyco]

If you find useful to access form.{whatever} you are creating intermediate components that knows too much. Such components are not compatible with intrinsic components which would pass all props down (React DOM warns about this) and those would not make use of form prop at all, unless they know about form prop.

This is actually powerful pattern which allows us to use Formik with UI libraries of out choice with small amount of work.

[VincentLanglet]

Sorry, I'm not sure to understand.

What is/will be the good pattern for this kind of component ?

import TextField from '@material-ui/core/TextField';
import React from 'react';

const FormField = ({ field, form, ...otherProps }) => {
  const error = form.touched[field.name] && form.errors[field.name];

  return <TextField {...field} {...otherProps} error={!!error} helperText={error} />;
};

const LoginForm = () => (
  <Form>
    <Field name="email" type="text" label="Email" variant="outlined" component={FormField} />
  </Form>
);

Not using Field ?

[Andreyco]

Yes. And you use Field in LoginForm scope ;)

Also, you can compose your FormField component this way

import TextField from '@material-ui/core/TextField';
import React from 'react';

const FormField = props => {
  return (
    <Field {...props}>
      {({ field, form, meta, ...otherProps }) => {
        const error = form.touched[field.name] && form.errors[field.name];
        return (
          <TextField
            {...field}
            {...otherProps}
            error={!!error}
            helperText={error}
          />
        );
      }}
    </Field>
  );
};

const LoginForm = () => (
  <Form>
    <FormField name="email" type="text" label="Email" variant="outlined" />
  </Form>
);

[johnrom]

This will have an added bonus of resolving types on the field, as form is actually a valid input attribute that specifies to which form an input belongs.