React-redux-form: React throwing an uncontrolled input warning

Created on 8 Apr 2017  路  6Comments  路  Source: davidkpiano/react-redux-form

The Problem

Thanks for the great lib! However I have been seeing a similar issue to the ones reported here:

Based on the those threads I thought that upgrading to at least v1.8.3 of RRF would solve the warning. However that has not been the case. I have tried v1.8.3 as well as the most recent v1.9.0 and the issue persists for my app.

Steps to Reproduce

I tried to do a minimal repro using your Codepen template but for unclear reasons the issue is not replicating there. Here's my attempt for reference: http://codepen.io/ryanheathers/pen/evwrQM

Instead I went ahead and pushed a minimal repro to Github: https://github.com/ryanheathers/form-test. Run npm start and try typing something in one of the inputs to see the issue appear.

Going out on a little bit of a limb, but perhaps this is an issue with the LocalForm component specifically? My app only uses LocalForm and I haven't attempted to repro with the standard Form component.

Most helpful comment

What if I added <Control.password> ?

All 6 comments

Thanks for this! I'll take a look tonight and get a fix out.

Hey, future humans!

I had the same problem with a custom password thingy (leveraging react-bootstrap)

The fix has been applied to Control.text, as you can see in the commit. If you just use normal "Control" it will still give you this trouble. Use "Control.text" with your password boxes.

@davidkpiano , I'm not sure how you want to fix this, you could apply the fix to the Control object in general, OR you could update your documentation here: http://davidkpiano.github.io/react-redux-form/docs/api/Control.html

Where it currently says:
You can add other input types to the basic <Control> component as an attribute: <Control type="password">

You could change it to:
You can add other input types to the basic <Control> components as an attribute: <Control.text type="password">

What if I added <Control.password> ?

That would be the sexiest option. I give you the thumbs up emoji. 馃憤

You are the best of men. Keep up the great work!

EDIT

Disregard my original comment; I discovered that the error was mine. Everything works as expected with no warnings. I didn't properly spread the return value of createForms onto the reducers object being passed to combineReducers. Somehow the

and components were successfully updating the store, but the modelValue changes weren't being communicated back to the components. That's why there was a mismatch between viewValue and modelValue and why my components were initially rendering without any value attribute on the HTML.

Sorry for my confusion!


ORIGINAL

@davidkpiano , I'm just getting started with RRF and immediately ran into this issue setting up a basic login form. I'm using v.1.16.3. I've read through all the previous issues you've closed for this matter, but I'm still not sure what the canonical solution is.

For each of these implementations:

<Control.input type='email' model='login.email' id='login.email' />
// or
<Control type='email' model='login.email' id='login.email' />
// and 
<Control.input type="password" model='login.password' id='login.password' />
//or 
<Control type="password" model='login.password' id='login.password' />

I get the typical warning: Warning: A component is changing an uncontrolled input of type email to be controlled. This is unexpected because the docs lead me to think this is the right way to do it. Quoting here:
"You can add other input types to the basic <Control> component as an attribute: <Control type="password""

I tried @andrewsplice 's tip about using <Control.text type="email"> and <Control.text type="password"> and that does prevent the warning. But it looks like you added the <Control.password > option. I just tried it and it worked fine. But this update to the source is not reflected in the docs. Would you like help with that?

It looks like <Control.email> didn't get its own component. Should the docs also be updated to demonstrate the <Control.text type="email"> solution to that? Or are you do you want to add <Control.email> as well?

I also came across a solution of my own as I was experimenting. After reading this section on Model and View Values in the Custom Controls article, I decided to try using props.mapProps to see if I could just bypass the this.state.viewValue that appears to be responsible for the actual value that gets rendered to the DOM element.

<Control
      type='email'
      model='login.email'
      id='login.email'
      mapProps={{ value: ({ modelValue }) => modelValue }}
/>

This also prevents the warning about switching between controlled and uncontrolled states, which makes me think that somewhere in the source code, there is a disconnect happening between the modelValue and the viewValue. I think it must be at the time of the app initializing, because when I look at the HTML that gets rendered initially, the <input type="email" /> has no value attribute on it, whereas when I use <Control.text type="email" /> it does get value="" on the element (rendering the default '' value from the model in Redux). No idea where the disconnect could be happening, but I wonder if it has something to do with empty strings being falsey. Sound plausible?

This made me curious: Why make your Control component have to deal with two sources of truth, one in the Redux store and one on local component state? Why not just make the Control component render whatever it gets from the model in the store?

Anyhow, I'd appreciate some clarification on the canonical solution for the problem. And let me know if you want help updating the docs with whatever you decide to go forward with.

Would you like help with that?

Yes please! I get to PRs pretty quickly, and can update the docs ASAP.

If you want to go ahead and make the other changes in a PR, I would be open to that.

Why make your Control component have to deal with two sources of truth, one in the Redux store and one on local component state?

Many reasons, one of the most obvious being debounced values, change-on-blur, performance, etc.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kallemakynen picture kallemakynen  路  4Comments

stutanne picture stutanne  路  4Comments

robinspark picture robinspark  路  4Comments

danielericlee picture danielericlee  路  3Comments

iBasit picture iBasit  路  4Comments