Formik: Initialization of status

Created on 28 Feb 2018  路  14Comments  路  Source: formium/formik

Bug, Feature, or Question?

Bug

Current Behavior

When including a reference to this.status.property in a Formik inner component, where property is determined after handleSubmit is called, initially referencing this.status.property results in error: Cannot find property 'property' of undefined

Desired Behavior

Reference to this.status.property should return undefined on component initialization.

Suggested Solutions

After a few hours of digging, and looking at this CodeSandbox, the current solution is to append this.status && before this.status.property so the conjunction short-circuits to false.

Given this is a basic JS fact of how objects evaluate, it may seem like the solution is obvious, but I found the documentation regarding how status is handled a little sparse.

Maybe there could be a initializeStatus property for the Formik component which allows you to specify status on page initialization?

  • Formik Version: 0.11.11
  • React Version: 16.0
  • TypeScript Version: N/A
  • CodeSandbox Link: https://codesandbox.io/s/ppnkqv78wq
  • OS: Windows 10
  • Node Version: 9.5
  • Package Manager and Version: npm 5.6.0
stale

Most helpful comment

I would recommend providing a default parameter for status in a destructuring. As follows:

<Formik
  render={({ status = { some: 'value' }) => ( ... )}
/>

Although status could be an empty object by default, what do you think @jaredpalmer?

All 14 comments

I would recommend providing a default parameter for status in a destructuring. As follows:

<Formik
  render={({ status = { some: 'value' }) => ( ... )}
/>

Although status could be an empty object by default, what do you think @jaredpalmer?

Had same problem tonight, and could solve it with the status && status.property that @trentfridey mentioned, but I think this situation will happen and will confuse people; I agree with having an initializeStatus prop, or at least give info on documentation on how to avoid this error.

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.

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

Any chance of this being reopened? I ran into the same issue.

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.

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

I just bumped into this same issue. You can fairly easily "initialize" the status with a connected component's componentDidMount() lifecycle method (kind of similar to how formik-effect uses a connected component's componentDidUpdate() lifecycle method to respond to changes in the form.)

But by that point it won't be invoked by React until after everything in the form has already been rendered at least once. So anything that uses formik.status still has to be written to render sensibly when formik.status is undefined.

So the workaround is to use formik.status && formik.status.whatever. Or use Formik's (undocumented) getIn(formik, 'status.whatever') method or lodash.get(formik, 'status.whatever'), neither of which will crash if they hit an undefined field.

@jaredpalmer would you consider adding an initialFormStatus? My use case is as @agwells mentions above where we set the status of the form on componentDidMount but:

  1. that misses the initial render
  2. if we had initialFormStatus we wouldnt need the setStatus call in componentDidMount

Its not make or break for us but thought since we have initialValues and isInitialValid it could be a valid addition

Can we reopen? Would love to have an initialStatus property on Formik.

Would love to have a stab at it too.

My use case is the following: based on some field in status, I would like to disable all fields. All my fields are using a light abstraction on top of Field. If I could set the initialStatus, I could retrieve status from inside each Field and set disabled based on its value.

Without initialStatus, the first render will show all the fields not being disabled...

Yeah, my use case is a lot like what you describe. I've got a form where sections of it start out as disabled form elements, and they can be "unlocked" for editing by clicking on a button for that section. Since this "locked/unlocked" state isn't really a form value as such, it seemed appropriate to put it into status.

But since writing my last comment, I've wound up putting them into values anyway. This was for two reasons:

  1. This issue, the lack of an initialStatus setting. Even with the status && status.whatever workaround, it still caused an unnecessary extra render at the start.
  2. I wanted to be able to skip validation for the locked fields, but status is not passed to the validate callback (whereas values is).

It still feels a little hacky, but it works pretty well. I just filter out these "status values" in my onSubmit() handler.

Indeed, that's another solution, but it does feel hacky :) You have to remember to filter out those values inside onSubmit, whereas status was supposedly designed for the notion of "form context".

It does feel like that status should be passed to validate as well.

Added in 1.5.0

Was this page helpful?
0 / 5 - 0 ratings