React-final-form: Issues with Typescript + React native

Created on 29 Dec 2017  路  9Comments  路  Source: final-form/react-final-form

Are you submitting a bug report or a feature request?

Feature request

What is the current behavior?

Type errors with react-native + typescript

What is the expected behavior?

No type errors :P

What's your environment?

I'm using react-final-form with react-native

"react-final-form": "^2.1.1",
"final-form": "^3.0.0",
"react": "16.0.0",
"react-native": "0.50.4",

Other information

There are two situations where I have type errors.

1. handleSubmit

The current type for handleSubmit is:

handleSubmit: (event: React.SyntheticEvent<HTMLFormElement>) => void

How can we deal with this in react-native?
onPress events of touchables have this signature:

onPress?: (event: GestureResponderEvent) => void;

2. Field extra props

Sometimes we need to pass some extra props to the underlying component of Field

            <Field
              name='firstName'
              component={TextInputField}
              style={styles.textInputStyle}
            />

In this case, the style prop is the extra one.
The type system complains because the props that Field is expecting are:

export type FieldProps = {
  allowNull?: boolean
  format?: ((value: any, name: string) => any) | null
  parse?: ((value: any, name: string) => any) | null
  name: string
  subscription?: FieldSubscription
  validate?: (value: any, allValues: object) => any
  value?: any
} & RenderableProps<FieldRenderProps>

Maybe we should allow anything here? :\ 馃憥

Most helpful comment

styled-components is a library compatible with both react and react-native (and it has completely different implementations for each one). The way it's API works is by exposing functions from styled-components/native. So if you are targeting web you import from styled-components and if you are targeting react-native, you import from styled-components/native.
Maybe we could expose a different component (under react-form-react/native) for react-native usage

All 9 comments

I think #84 handled the first one, right @cosmith?

Is there a way to say, "This stuff, and anything else" in type definitions?

Hmm, maybe:

interface IFieldProps {
     bla: bla;
    [x: string]: any ;
}

But I'm wondering if this is a good practice

I'm largely ignorant of TS, so don't feel like I can make a judgement call on this. First check other React component libs, and if it seems like something people do, I'd be happy to accept a PR with this change.

Extra props is a duplicate of #79, it's fixed on master already.

@rafaelcorreiapoli I've never used react-native but looking a the definitions, NativeSyntheticEvent does not extend SyntheticEvent, hence the problem that you describe.

Surely other libraries (compatible with both react and react-native) encountered this problem already. Do you know of any good example we can take inspiration from?

Is it a good practice, idk but this pattern is used all over the place.

It is a way of saying "here are the props the lib cares about, you can pass anything else but we won't use it". As long as we maintain the "official" attribute list, we're OK.

styled-components is a library compatible with both react and react-native (and it has completely different implementations for each one). The way it's API works is by exposing functions from styled-components/native. So if you are targeting web you import from styled-components and if you are targeting react-native, you import from styled-components/native.
Maybe we could expose a different component (under react-form-react/native) for react-native usage

Hello there!

Are there any updates on this issue?

One more issue with React native. onPress and handleSubmit

       <Form
          render={({ handleSubmit }): JSX.Element => (
              <TouchableOpacity onPress={handleSubmit}>
                Submit
              </TouchableOpacity>
          )}
        />

Type '(event?: SyntheticEvent<HTMLFormElement, Event> | undefined) => Promise<AnyObject | undefined> | undefined' is not assignable to type '(event: GestureResponderEvent) => void'.

Published fix in v6.3.4.

Was this page helpful?
0 / 5 - 0 ratings