Formik: Props being set as `values` when passed to a `withFormik` wrapped component

[anthonator]

Current Behavior

When you pass props to a component that is using withFormik the props are present as values.

Steps to Reproduce

Pass props into a component using withFormik.

const MyFormikComponent = withFormik({})(SomeComponent);

<div>
  <MyFormikComponent someKey="someValue" />
</div>

Inspecting values within SomeComponent will show that {someKey: 'someValue'} is present.

Expected behavior

values should not contain props passed to component.

CodeSandbox Link:

https://codesandbox.io/s/9387xomp5r

---

• Formik Version: 1.0.0-beta.5
• React Version: 16.4.1
• TypeScript Version: N/A
• Browser and Version: Chrome Version 67.0.3396.99 (Official Build) (64-bit)
• OS: macOS 10.13.5 (17F77)
• Node Version: 10.5.0
• Package Manager and Version: yarn v1.7.0

[jaredpalmer]

This is the default behavior of withFormik. More specifically, withFormik will move all non-function props to values if you do not specify mapPropsToValues. The thinking was that you could quickly spread items into forms... like <MyUserForm {...user} /> an skip a step.

[anthonator]

Ah, OK. I must have missed that in the docs.

From my perspective, I think this violates the law of least surprise. This definitely wasn't the behavior I was expecting. Tools like Redux take the opposite approach which I think makes more sense.

Just my perspective though.

Feel free to close if you don't feel there's anything to discuss or is actionable.

[jaredpalmer]

@anthonator I agree with you. I honestly haven't written a new form using withFormik() since I introduced the render prop ~11 months ago, but i do somewhat agree. This is the first time someone has mentioned this as an issue, but if there are other people that agree that this is confusing we can put up a warning if mapPropsToValues is not present and then eventually an error in future release.

[anthonator]

I think either requiring mapPropsToValues or reversing the default (only include props if mapPropsToValues is present but not requiring it) makes sense.

For me, my concern has been that at the moment I'm sending data over the wire that I didn't realize was coming in through props. So I'm 1) inadvertently bloating the amount of data going over the wire and 2) transmitting data I didn't realize I was transmitting which could have some security implications.

I think it's a generally good practice to require people to opt-in rather than opt-out by default when it comes to data.

I'm interested to hear other's opinions as well.

[anthonator]

@jaredpalmer do you have contributors you can ping to chime in on this?

[stale[bot]]

Hola! So here's the deal, between open source and my day job and life and what not, I have a lot to manage, so I use a GitHub bot to automate a few things here and there. This particular GitHub bot is going to mark this as stale because it has not had recent activity for a while. It will be closed if no further activity occurs in a few days. Do not take this personally--seriously--this is a completely automated action. If this is a mistake, just make a comment, DM me, send a carrier pidgeon, or a smoke signal.

[publicJorn]

This seems fixed already. See #480
Issue can be closed

[stale[bot]]

Hola! So here's the deal, between open source and my day job and life and what not, I have a lot to manage, so I use a GitHub bot to automate a few things here and there. This particular GitHub bot is going to mark this as stale because it has not had recent activity for a while. It will be closed if no further activity occurs in a few days. Do not take this personally--seriously--this is a completely automated action. If this is a mistake, just make a comment, DM me, send a carrier pidgeon, or a smoke signal.

[stale[bot]]

ProBot automatically closed this due to inactivity. Holler if this is a mistake, and we'll re-open it.