Setting state values manually about react-use-form-state

[wsmd]

Hi @hcavalieri, Thanks a lot! 😊

The only issue I have with this hook is the fact that you only pass down formState.current through the hook, meaning we're locked if we need to set state manually.

Out of curiosity, how would retuning something other than formState.current help in your situation? While I understand the limitation of not being able to set a value manually, I don't understand how that is an issue caused by that fact that I'm passing formState.current.

That said, the only challenge I keep facing up when I think about manually updating a value is handling validity, touched, etc for these values. For example, validating an input requires access to the underlying DOM node since validation is fired on both the blur and change event which provide access to the event target.

The only option I can think of right now is adding something like input.forceUpdate(name, value) method that allows the developer to set the value programmatically with only one caveat: it has to skip validation - It's up to the developer to ensure the value being set is valid! Maybe one can run the value through the same validation criteria they are expecting their users to respect.

The more think about this the more I feel comfortable with skipping validity and touched states (by setting them to true) and clearing any existing errors. This is important in case the form is blocked by such inputs – the value is set programmatically after all, and you are probably using the validity/touched/error state to display some validation errors to your users. If the value is set programmatically is invalid, and I somehow managed to validate the value using forceUpdate, that will leave users confused.

So, a simple example of this would look like this:

function App() {
  const [formState, input] = useFormState();

  const onPageChange = React.useCallback(async e => {
    if (e.target.validity.valid) {
      const meta = await myFakeAPI.getPageMeta(e.target.value);
      // manually updating the input value
      input.forceUpdate('title', meta.title);
    }
  });

  return (
    <form>
      <input {...input.url({ name: 'page', onChange: onPageChange })} />
      <input {...input.text('title')} />
    </form>
  );
}

What do you think?

[stclairdaniel]

This is something our team needs as well - sometimes we'll have a field that strictly determines the value of another field, and I'd like to be able to set it manually.

[hipdev]

Hey guys, a newbie here, how are you cleaning the form after submit? I have an issue with that :(

[DarrylD]

can something this work:

const values = {name: 'bob', age: 10} //lets say we have 20 fields...
input.forceUpdates(values);

Thinking of the cases where many fields needs to be updated (my current case).

[hdoro]

Thanks for the quick and thorough answer, @wsmd !

This works perfectly for my use case - in fact, your example was my challenge itself 😝 - but I'm not sure about other people's... For @DarrylD 's case, I believe a simple for loop would do it, and then React could batch-render the state updates - there shouldn't happen a drop in performance.

I didn't go through your whole API, Waseem, but if this change doesn't incur into conflict and still helps @stclairdaniel and others, it's a big thumbs up for me 👍 Thanks for the solution, btw, I agree with 100% of your thought process 💃

[DarrylD]

For @DarrylD 's case, I believe a simple for loop would do it, and then React could batch-render the state updates - there shouldn't happen a drop in performance.

While I agree, I do believe this will be a common thing, amung users. If everyone is doing the same looping, might be a good idea to just bake it in.

I think to clear the entire form (think of clearing upon adding something) with this approach may also be a good use case.

Just my 2cents, overall love the idea of the project! My only deal breaker is no simple way to clear/change the values in bulk.

[hdoro]

You're absolutely right, Darryl! I didn't think of clearing the form and, indeed, updating multiple values is a common use case...

forceUpdate could have an internal type checking that, if you pass down 2 arguments - the first being a string and the second a value - then it'd update the named property, else, if you pass down an object, it'd loop through Object.keys and update each of them accordingly. However, this approach doesn't cover clearing the form quite well: would we need to pass down an object with all keys but empty values?

[DarrylD]

would we need to pass down an object with all keys but empty values?

that should be fine!

[wsmd]

Thanks for the feedback, everyone!

You'll be able to set values of input values manually in the next release 0.10.0 which will be published very soon! 🎉

https://github.com/wsmd/react-use-form-state#updating-fields-manually

Unfortunately, I won't be supporting setting multiple values at once. However, there will be a new method to clear the entire form since that's probably the most common use-case for bulk update from what I've seen in this discussion.

https://github.com/wsmd/react-use-form-state#resetting-the-from-state

The reason I won't be including bulk update is because of the added complexity it brings to the library - it will be a maintenance burden eventually; removing features is far more harder than adding them 😄. The goal with this library is to keep it simple yet flexible enough to allow the developers to do whatever they want. If bulk update is truly necessary a small Object.keys or for..in loop should do the trick.

Thanks!

[melloc01]

That's great, thanks @wsmd!

I was hoping for this to be released so I could use on my "ArrayField" use case that received new props and had to set input states accordingly.

Although I think this was really missing feature, I think a declarative way would be a better a approach, what do you think? We could achieve that by having a two-way data-bind on the value prop, just like a normal input:

<input {...inputs.text('name')} value={props.name} />

if props.name changes, the form state field also does - sorry I didn't have time to look at the source code, not sure how much that'd impact or if it is even feasible, just brainstorming here.