-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Field props are not typed #2086
Comments
I ended up doing this: import { Formik, Field, Form, FieldProps } from 'formik'
import TextField from '@material-ui/core/TextField' interface FormValues {
title: string
} <Formik
initialValues={initialValues}
validationSchema={schema}
onSubmit={onSubmit}
render={formikBag => (
<Form>
<Field
name="title"
render={({
field,
form: { isSubmitting },
meta,
}: FieldProps<FormValues>) => (
<TextField
{...field}
disabled={isSubmitting}
type="text"
variant="outlined"
error={meta.touched && !!meta.error}
helperText={meta.touched && meta.error}
label={'Titel'}
fullWidth
/>
)}
/>
</Form>
)}
/> |
Looks like it's a bug in TypeScript or something |
If I interpret the type info in Field.d.ts correctly, render gets passed a props argument of type FieldConfig instead of FieldProps in your case. If you look at Field.d.ts, there are quite a lot of places where 'any' type is used. |
It would be better if the unkown type was used https://mariusschulz.com/blog/the-unknown-type-in-typescript |
The following definition of FieldProps is incorrect in my humble opinion. FieldInputProps and FieldMetaProps takes a type parameter of V to denote the type of a field value. However, FormikProps expects a type parameter to denote the type of the values of a form. So, in FieldProps, FormikProps shouldn't take V as the type parameter. This hasn't caused a problem in most project, I think, primarily due to the fact that most project are using the Field component which set V to any. However, if you start using useField in Typescript, it causes type error. export interface FieldProps<V = any> {
field: FieldInputProps<V>;
form: FormikProps<V>; // if ppl want to restrict this for a given form, let them.
meta: FieldMetaProps<V>;
} |
Fixed in 2.1. |
@jaredpalmer could you please provide a minimal code snippet using To be honest explicit typing would make sense because without it the types derived from the type of the field value would have |
@andrewpeterprifer @jaredpalmer This is still an issue for me too. I'm on Formik 2.1.3 and Typescript 3.7.5 and am receiving these implicit any errors. Error example: "Binding element 'setSubmitting' implicitly has an 'any' type." Has anyone found a consistent solution to this? |
Also experiencing the same issue with Formik 2.1.4 and Typescript 3.7.4. |
@davidwilson3 I think explicitly typing the field props will always be necessary because otherwise TypeScript would have absolutely no way of telling which field a certain Field component belongs to. My complaint was more directed to the documentation. @jaredpalmer maybe the Field component could be made more ergonomic by letting it accept a generic type parameter like useField does? |
Same issue Formik 2.1.4, typescript 3.8.3 |
Any updates on this? Same issue in Formik 2.1.5, typescript 3.8.3 |
Maybe you need to write this <Formik<FormValues>
abc={etc} /> |
This is still not fixed in v2.2.6 |
Two years later and field props still without typing. |
Issue still persists in v2.2.9 with |
It's not advisable to create a new functional component in each render to pass to the component prop, as React will not be able to tell they are the same component. If you want to use render props, it is recommended to use a child function which should be typed correctly automatically. Types overhaul is targeted for 3.1 and a preview is possible by searching PRs for "Strongly Typed Formik v3", though your particular case is not tested as |
I did use render props with a child function but <Field name="period">
{(props: FieldProps<string>) => ( // `props` is `any` without `FieldProps`
<select {...props.field}>
<option value="current">Current</option>
<option value="next">Next</option>
<option value="both">Both</option>
</select>
)}
</Field> |
One way around this problem is creating custom component and using type InputFieldProps = InputHTMLAttributes<HTMLInputElement> & {
label: string;
name: string;
textarea?: boolean;
};
export const InputField: React.FC<InputFieldProps> = ({
label,
textarea,
size: _,
...props
}) => {
const [field, {error}] = useField(props);
... |
Problem still occurs. |
@jaredpalmer given a snippet below, what types should we use? You said this is fixed but it doesn't seem so:
|
FYI Formik's documentation is misleading and should be corrected to avoid confusion by TS consumers. While Formik was written in TypeScript, this issue makes it clear that Formik does not yet support strong typing, and therefor intermediate/advanced use cases (e.g. Pages I checked just now: |
https://chakra-ui.com/docs/components/form-control/usage#usage-with-form-libraries
well that was a lie |
This is still an issue for me. I'd appreciate any help.
|
This library hasn't had activity in quite a while. You can look at my implementation here which came close to solving the problem: But I think React Hook Form has since solved a lot of the advanced types required for forms in their library since then. |
@johnrom I really appreciate the mention of the other library. Thank you so much I am going try that one. |
🐛 Bug report
Current Behavior
FieldProps are not typed appropriately when using
<Field>
However, manually typing it seems to fix the warning
I implemented the Field based on the TS guide
Expected behavior
I expected TS to not give a warning here since I followed the example of the guides.
Reproducible example
Here is a sample: https://codesandbox.io/s/hopeful-sunset-5n7ud
Suggested solution(s)
My knowledge of TS may not be deep enough to say whether it TS should error on this, or if it really is the case that I need to coerce the props to
FieldProps
in the last codesandbox sample.If that's the case then the guide should be updated, and I am happy to do it and submit a PR.
Additional context
Your environment
The text was updated successfully, but these errors were encountered: