I believe this is also the cause of my issue:

I am testing the upgrade to redux-form 8.0.4 using jest and enzyme's mount to mount a connected redux form with initialValues.

I am getting PropTypes warnings that required values are the wrong type (required boolean fields being passed empty strings). Logging renders I see a first render with empty string values, followed by a second render with the correct values. The first render seems to be generating the warning.

Also get this error. props.input.value is always an empty string on componentWillMount, componentDidMount and first render call. I cannot initialize my forms without propTypes errors
https://codesandbox.io/s/my7x8m83ox

the same error with sync validation and array... I don't get initial value of array to validate function in first render

Hi @erikras, any thoughts about this? May be any temp workaround? For my use cases redux-form v8 is completely broken because of this issue.

componentWillMount is deprecated

@jjosef You are correct. However, to clarify, moving this call to a constructor (as per the deprecation notification) shows the same problem.

If there's something else you think I should be doing, please let me know!

I'm running into this same issue - I'm seeing the initialize action dispatched to Redux, the store is showing the correct values for both the values and initial keys, but then the individual Field components are all getting empty strings as values (however, if I inspect their meta props, the meta.initial prop is showing the correct initial value that the field should be using).

Has anyone had any luck getting around this?

Also hitting this same issue with empty strings for props.input.value but only affecting a custom component that receives an JSON object for initialValue. All other normal fields seem to be working. Not managed to find a workaround yet.

initialValues don't seem to be loaded into the redux form state until after an initial render. Several of my components rely on there being an initial value so I made a helper decorator for a quick fix for those components so I don't have to rewrite all my components, just decorate them. The decorator simply doesn't render the form until it's initialized.

reduxFormRequireInitialized.js

import React from 'react';

/**
 * redux-form introduced a breaking bug in 8.0 where forms are no longer initialized before the initial render. Some of our forms rely on this behavior. To avoid issues caused by this bug, we can decorate those forms with this decorator to hold rendering until the redux-form is initialized.
 */
export default Component => (
  props => {
    if (!props.initialized && props.initialValues !== undefined) {
      return null;
    }

    return (
      <Component {...props} />
    );
  }
);

The decorator simply doesn't render the form until it's initialized

I suppose this can lead to blinks or UI shifts

I've just encountered this as well. I think the problem is that react-redux has slightly changed behaviour after switching to the new context API. The initialize action is fired and the store is updated before rendering the connected field, but react-redux serves up a snapshot from when the render began. While this is annoying in this case, it does seem like a more correct behaviour.

I think it can be very simply fixed by reading value from initialValues instead of formState before initialization, a one-line change. I'll put together a pull-request.

Redux Form 8.0.4: https://codesandbox.io/s/0yvykqqxwl will work better with constructor like this :

  constructor(props) {
    super(props)
    console.log(this.props.input.value);
  }

then modal doesn't render an empty string

Issue is gone after updating to [email protected]

Upgrading to [email protected] and [email protected] appears to have introduced this problem into my application.
Upgrading to [email protected] and [email protected] does not appear to have got rid of it :(

Any news on that facing the same issues...

@eugensunic Please read the deprecation notice and consider using final form...

@levino I already have , currently on 7.4.2 and the next step in migration only.

This might be resolved with 8.3.10. From a first look, I didn't encounter the problem anymore.