final-form / final-form/react-final-form

[feedback] 100% typechecking for deep field names and values

Open
#856 4 comments 3 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
7.4k
Forks
497
PR merge metrics
No merged PRs in 30d

Description

So the philosophy docs state that

> React Final Form provides strong typing via both Flow and Typescript to allow you to catch common bugs at coding time.

But this is far from 100% true; it's obvious that react final form uses dynamic field names that it can't typecheck, just like redux form. Hence I don't get compile time errors about using the wrong field names or expecting the field values to be a certain type. For example when I rename a field in refactoring, it would be nice to get compile errors about every place where I'm using the old field name. I've caused numerous regressions when refactoring complex forms because I can't get compile errors like this right now.

I mean it seems like you can pass a type parameter like `>` but doesn't seem like anything can typecheck that `get(formValues, name)` is guaranteed to be a string.

Have you thought about redesigning the API to make the values object tree 100% strongly typed? Flow and Typescript don't have a way to deep pick a property type via string path as far as I know so it seems like we would need to pass in some kind of getters/setters to Field instead. Checking top-level fields is currently possible with string names, but not fields inside nested objects and arrays.

Seems like we would have to bind values types to `Form` and `Field` components via an HoC like

```ts
type InitialUserFormValues = { username: string | null | undefined }
type ValidatedUserFormValues = { username: string }

const {Form, Field} = createForm()

const validateUsername = (value: string | null | undefined): {error: string} | {value: string} => {
if (username == null) return {error: 'is required}
return {value: username}
}

const handleSubmit = async (values: ValidatedUserFormValues) => {
...
}

const MyForm = () => (

{/* not sure what form getters and setters for deep fields would have to take... */}


)
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.