Cannot use a higher-order function in Field Validation

[duro]

Are you submitting a bug report or a feature request?

Bug

What is the current behavior?

When using field level validators, I am unable to use a higher order function to produce the validation function

This works:

const required = value => (value ? undefined : 'Required')

<Field
  label="Email"
  name="email"
  component={InputField}
  validate={required}
  placeholder="email"
  type="text"
/>

This DOES NOT work:

const required = (msg = 'Default Message') => value => (value ? undefined : msg)

<Field
  label="Email"
  name="email"
  component={InputField}
  validate={required('Message Override')}
  placeholder="email"
  type="text"
/>

What is the expected behavior?

I would expect to pass into the field validator a returned function that matches the validator interface even if it was produced by a higher order function

Sandbox Link

https://codesandbox.io/s/G6ARklAMr

What's your environment?

Redux Form: 7.0.3
OS: macOS
Browser: Chrome 60

Other information

[duro]

Just reverted back to 6.8.0 and this works as expected.

[danielrob]

This is expected behaviour see #3271.

[duro]

@danielrob Cool. I followed through on the threads and updated docs, but I'll be honest. This is still a very confusing change to me. I guess I need to switch to using a bound method instead of a lambda created at render time, but I'm still not really sure.

[danielrob]

I fully admit my documentation update for this was minimal... and that while this change makes the library more powerful, it also makes the consumption more advanced.

Your help would be appreciated to alleviate this... perhaps you could think about where in the documentation / how this could be explained to make it clear?

Edit: I hadn't actually realised that this affects all inline validation functions regardless of whether they were higher order functions or not. See the other ticket.

[gabrielhpugliese]

Could you please enlighten me here? What's the cause for this not to work? I didn't get it yet.

[danielrob]

@gabrielhpugliese ok the latest:
You must define your validation functions outside of your render method. Additionally if they are a higher order function which receive props you should instantiate them when the component mounts / on instantiation.

So either (option 1):

const myvalidate = (validateParams) => ( /* some function on validateParams */)
const MyComponent = () => {
  <Field
    validate={myvalidate}
  />
}

Or something like (option 2):

const myValidate = config => (validateParams) => ( /* some function of validateParams & config */ )

class MyComponent extends React.Component {
  constructor(props) {
    super(props)
    this.validate = myValidate(props)
  }

  render() {
    <Field
       validate={this.validate}
    >
  }
}

Or (option 3)

import { memoize } from 'lodash'

const myvalidate = memoize(config => (validateParams) => ( /* some function on validateParams & config */))
const MyComponent = (props) => {
  <Field
    validate={myvalidate(props)}
  />
}

Please note I'm just doing this off the top of my head, and I'm primarily an issues helper and haven't tried this on my personal project yet, so this is just my understanding presently.

[erikras]

I'm more than just "an issues helper". 😄 Two things:

1. Okay, this is silly. The form doesn't need to be reregistered, the form component just needs to be notified of a new validation function.

2. That said, and perhaps I should write a medium post about this...

Creating a new function for a prop in render() is an anti-pattern.

It [almost always] requires that the child rerender itself, when require('This field is required') always generates the exact same function. Memoizing can get you some benefits here, for sure, as would @danielrob's other example of saving them as this.validateUsername-type members.

It would be wonderful if you could do validate={require('Error message')}, because it looks so beautiful, but that's not the way React works at the moment.

Hope that helps.

[gabrielhpugliese]

Thanks for the info!

What if I depend on a prop? What's the correct way to approach in a stateless component? For example:

const { translate } = props;
<Field
  label="Email"
  name="email"
  component={InputField}
  validate={required(translate('Message Override'))}
  placeholder="email"
  type="text"
/>

I really didn't want to couple required function to the translate function.

[gabrielhpugliese]

I also have another example where I have a range and the message should be something like "Choose between 1 and 10" but the range is configurable and dynamic. I'm kinda struggling with that.

[danielrob]

I'd tweak the wording to be super explicit there:

Defining a function in your render for the purpose of passing it as a prop to a child component is an anti-pattern.

BUT

@erikras in the HOF case described in this issue, this doesn't fly:

Suppose I have a field definition which somewhere up the chain get's passed as a prop fieldDef:

{
  type: 'text',
  max: 5,
}

And I want to create a max 5 validator where the max is 5 from fieldDef.

Well, if Field accepted two props validate, validateParams and bound those for you on mount, you could avoid this anti-pattern, but it doesn't, and I'm not sure it should, because I think in our specific case here the 'anti-pattern' is the preferred option because in this case it's not the anti-pattern.

The whole point of this change is that you can change a validator function on a mounted component:

• But if you're never going to do that, then use option 2 which creates your function once, on mount - and never changes again in your render regardless of new props (so it's not even a case of the anti-pattern anyway).
• If you might do that, then option 3 (memoization) or componentWillReceiveProps with props change checking are your only options, but you are forced to follow the anti-pattern. But the only reason it's an anti-pattern is because it causes unnecessary renders, which memoization avoids... so again, not an instance of the anti-pattern.

Otherwise we need to change the Field api to something like:

validateParams - parameters to bind to the validate function [optional]
validate - (...validateParams, value, allValues, props) => error [optional]

And have Field do the binding for you.

Unless I'm somehow mistaken - please enlighten me!

Relevant reading confirming the anti-pattern statement:

Binding parent props to passed function:
https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-no-bind.md#protips
https://ryanfunduk.com/articles/never-bind-in-render/
https://daveceddia.com/avoid-bind-when-passing-props/ (See Bonus: Passing Arguments Without Bind at the end)

Passing just any on the fly made function in general:
https://medium.com/@esamatti/react-js-pure-render-performance-anti-pattern-fb88c101332f
https://daveceddia.com/avoid-bind-when-passing-props/ (See way #3)

@duro I'm going to humbly apologize and re-open this as it clearly warrants more discussion... but I'll throw the discussion tag on it.