reset individual input state

[bluebill1049]

Context

The current status of using reset API can be quite complex when it comes to resetting an individual input state. We would like to expose a new API or config to combat this problem, so developer experience can be enhanced. At the moment, we have two API purposes in the planning and would like to get the community's thoughts over which.

Props

• declarative API for reset a single field state update
• more performant than reset the entire form

Cons

• increase in package bundle size.
• increase APIs or config

Proposal

Here are the two options which we are considering:

Option A

setValue(‘name’, { shouldReset: true }); // reset field value to default and reset all field state
setValue(‘name’, undefined, { shouldReset: true }); // reset field value to default and reset all field state
setValue(‘name’, ‘newValue’, { shouldReset: true }); // reset field value to 'newValue' and reset all field state

Option B

resetField(‘name’);  // reset field value to default value and state
resetField(‘name’, ‘newValue’); // reset field state to update default value
resetField(‘name’, { keepError: false, keepTouch: false, keepDirty: false }) // keep some of the filed state

Option A: leverage existing API, no need to remember another, the only concern is the setting value to undefined it's not that intuitive.

Option B: new API more flexible and more declarative and self-explanatory, however increasing the amount of the API for the lib.

Sytnax

The following is the good outcome with a new API focused on resetting input state/value.

resetField('inputName', {
  keepDrity: false,
  keepError: false,
  keepTouch: false,
  defaultValue: '' // when provided with defaultVlaue update both input value and internal defaultValues
})

PR (draft)

#6891

cc @barrymay @kotarella1110 @jorisre @wdfinch @getTobiasNielsen

[mysuf]

I got one more proposal which could possibly alow to reset multiple fields by one row instead of using for loop:

reset({ ...keyValuePairs }, { merge: true, ...otherResetOptions })

Otherwise I vote for B as it provides also a way to set state of input.

[bluebill1049]

ideally, we want to avoid bulk updates for set filed value and state, as users can have their own abstraction and keep all API consistent as well. eg setError setValue both share the same syntax set(name, value, options)

[kugimiya]

Hello. I would like to take this moment to thank for the cool library. ^^`

I think it would be great if you could resetting a specific field directly to the reset function. I tried to figure out how reset works under the hood, it seems you can write something like this: reset({ name: '' }, { keepValues: true }).

But I read the @bluebill1049's answer for @mysuf, so I join him and vote for option B.

[bluebill1049]

Thanks for the participation and your voice counts 👍

[getTobiasNielsen]

I wonder if it's cleaner to keep some of it separate in option B

// Option B revised 
resetField(‘name’);  // reset field value to default value and state
resetField(‘name’, { keepError: false, keepTouch: false, keepDirty: false }) // keep some of the filed state

setDefault(‘name’, ‘newValue’); // change default field value

RANT: (feel free to disregard)
I also wonder if it's a good idea to have a resetField along side a setValue
For reset currently:

For controlled components like React-Select which do not expose a ref prop, you will have to reset the input value manually with setValue or connect your component via useController or Controller.

This essentially means you have two separate reset paths currently, which is very counter intuitive. I think having as little rules as possible makes for the best API.

Maybe it's better try try and make a setField that can both reset a field and it's state, but also set a value for the field, along with state.

setField(‘name‘, ‘newValue‘, { validate: true, dirty: true })
// sets field value and makes it validate and sets it as dirty

setField(‘name‘, { error: { type: "error", message: "Ups!"}, touch: false, dirty: false })   
// losses the touch(ed) and dirty value, but sets a new error,
// alternatively could also receive a boolean, to specify 
// if it should loose, or keep the current error.

setField(‘name‘, { resetValue: true, error: false, touch: false, dirty: false }) // Resets all state and the specifically the value

// -------
setField(‘name‘, ‘newValue‘, { reset: true, updateDefaultValue: true })
OR
setField(‘name‘, { reset: true })
setDefault(‘name’, ‘newValue’); // change default field value

// Resets the field, updates the default, but also gets dirty
setField(‘name‘, ‘newValue‘, { reset: true, updateDefaultValue: true, dirty: true })

[bluebill1049]

perhaps this is the middle ground:

resetField('name', {
  value: '...'
  keepDirty: true,
  keepValue: true,
  keepDefaultValues: true
})

config are all optional

resetField('name')

[bluebill1049]

But I do like to keep API consistent as well, which is why name value and config

[getTobiasNielsen]

Yeah, here you could reset dirty, but keep the value, which seems more modular

keepDefaultValue without the s

[getTobiasNielsen]

But I do like to keep API consistent as well, which is why name value and config

I want the users to suffer for my vanity

[bluebill1049]

It's good feedback! At least most voice so far all lean towards option b.

[TadejPolajnar]

I prefer option B it seems closer to the current react hook form API.

Here's my question, what happens if the resetField is called with the field name that does not exist? Would that add a new field or it would just ignore it?

[bluebill1049]

Thanks @TadejPolajnar It would be just ignored, which will be documented into the doc. so strictly registered input name for the reset action.

[barrymay]

Personally I like resetField (option B), but to be clear, is this supported?

resetField(‘name’, 'value', { keepError: false, keepTouch: false, keepDirty: false }) // reset state w/ options but with new default value

If you did put it the object (as mentioned in the thread with @getTobiasNielsen), maybe make it clear what the value is:

resetField('name', {
  newDefaultValue: '...'
  keepDirty: true,
  keepValue: true,
  keepDefaultValues: true
})

[getTobiasNielsen]

Reads better this way.

[bluebill1049]

resetField('name', {
  defaultValue: '...',
  value: '....',
  keepDirty: true,
  keepValue: true,
  keepDefaultValues: true
})

thanks @barrymay and @getTobiasNielsen ^ perhaps this covers all

[bluebill1049]

resetField('name', {
  defaultValue: '...',
  keepDirty: true,
  keepValue: true,
  keepDefaultValues: true
})

value is removed, only setValue should do that.

[wdfinch]

Option B. I'd rather have more functions that are focused and simple rather than a few functions that are complex and can be used for many cases. Using setValue would also have the limitation of not being able to pass in those extra options or having it be really messy. I think resetField is great.

[bluebill1049]

sounds good 👍