Definitelytyped: [redux-form] missing config-props on HOC

[ragtime]

• [x] I tried using the @types/redux-form package and had problems.
• [x] I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript
• [x] I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).
• [x] I want to talk about redux-form/reduxForm.d.ts.
  
  
  
  • The authors of that type definition are cc/ @CarsonF
  
  

According to the redux-form manual all config options are available as props on the wrapped component as well (http://redux-form.com/6.6.3/docs/api/ReduxForm.md/)

IMPORTANT: All of these configuration options may be passed into reduxForm() at "design time" or passed in as props to your component at runtime.

The type for reduxForm should therefore be something like

export function reduxForm<FormData extends DataShape, P, S>(
    config: Config<FormData, P, S>
): FormDecorator<FormData, P, S>;
// [...]
export interface FormDecorator<FormData extends DataShape, P, S> {
    <T extends ComponentConstructor<P & FormProps<FormData, P, S>>>(component: T): ComponentConstructor<P & Partial<Config<FormData, P, S>>>;
}

to use the new component according to the redux-form manual.

This would help in the following scenario

const TestForm = reduxForm({
    form: 'myform'
})(Form);
// [...]
<TestForm initialValues={...} onSubmitSuccess={...} />)

but breaks the usage as class-decorator

@reduxForm<FormData, any, any>({
    form: 'myForm'
})
class MyForm extends Component<any, any> {

The current definition of FormDecorator seems to not include this option due to a ts limitation as mentioned in redux-form/reduxForm.d.ts:

This is not entirely correct but Typescript expect input and output for decorators to be the same type Because of that, React HoCs can't be fully defined.

As decorators are still an experimental feature in ts I would prefer to drop the support for decorators and have the standard case correctly typed. The problem is that this would break the code if you already use the decorators.

Is there any solution for this problem?
Maybe we could provide different packages with and without the experimentalDecorators option.

[ragtime]

A workaround is to use the following module augmentation (save as *.d.ts file):

import {FormDecorator, DataShape, FormProps, Config} from 'redux-form';

declare module 'redux-form' {
  export function reduxForm<FormData extends DataShape, P, S>(
      config: Config<FormData, P, S>
  ): FormDecorator<FormData, P, S>;

  export function reduxForm<FormData extends DataShape, P>(
      config: Config<FormData, P, any>
  ): FormDecorator<FormData, P, any>;

  export function reduxForm(
      config: Config<any, any, any>
  ): FormDecorator<any, any, any>;

  export interface FormDecorator<FormData extends DataShape, P, S> {
      <T extends ComponentConstructor<P & FormProps<FormData, P, S>>>(component: T): ComponentConstructor<P & Partial<Config<FormData, P, S>>>;
  }
}

[Grmiade]

Is a PR planned?

[ragtime]

@Grmiade This would mean to drop the support for experimentalDecorators and therefore potentially breaking existing code.
Maybe the original authors @CarsonF @aikoven @LKay have more insight on this topic?

[LKay]

HoC's for react are not exactly a ES7 decorators but rather decorator like behaviour functions. It's a common issue with typescript to properly define decorators. Typescript expects decorator function to return exactly the same output and input type to work properly and inject some internal logic transparently. In my opinion experimentalDecorators and using @foo syntax should not be used too much.

Btw. Since redux-form in version 7 got released it's good time to review definitions and possibly introduce some breaking changes such as renaming interfaces etc. I'll start working on it soon.

[pierre-H]

Any news ?