onChange multiple fields #1081

simplecommerce · 2021-12-23T16:04:55Z

simplecommerce
Dec 23, 2021

Hi, in my current project, I am making a field dependent on another, so that it disables/updates itself based on another field's value.

I am using onChange in order to update the fields that need to change based on the other field.

My issue, is I have multiple fields to update, and I am thinking that its not really efficient to call onChange multiple times.

Is there a way to update the model directly instead in one change?

For example:

Instead of doing

onChange("fieldA",false);
onChange("fieldB",false);
onChange("fieldC",false);
onChange("fieldD",false);
onChange("fieldE",false);

I would do

onChange(model => ({
   fieldA: false,
   fieldB: false,
   fieldC: false,
   fieldD: false,
   fieldE: false  
});

I know this might not be possible right now, but what do you think? Or is there a better way?
Or are you already waiting for other onChange calls so it isn't re-rendered multiple times?

Sorry if I am not clear.

radekmie · 2023-03-10T12:54:57Z

radekmie
Mar 10, 2023

We got back to it (it took us a while), and we think that:

It's less of an issue with React 18 batching.
We've implemented uniforms on even more projects till then, and didn't have a need for that.

To sum up, we're still considering this functionality, but we'd rather limit the API and have "one correct way" to do everything instead.

0 replies

radekmie · 2022-01-10T10:42:10Z

radekmie
Jan 10, 2022

Hi @simplecommerce, sorry for the late response. Yes, calling onChange is a little wasteful, especially the changedMap resolution and AutoForm calculation of the next model. I was thinking about a solution for that myself, as it also happens in our projects, but with no clear outcome so far.

Yo* ur proposal of the "updater" form, similar to the setState one, is great overall. However, it's unclear to me, how it should behave exactly. Ideally, it'd work just like setState, but then scheduling a few changes would require us to do some extra bookkeeping and it's not always possible (e.g., a BaseForm without onChange). There's also a problem of how to update nested values, i.e., whether we do deep merge or not (probably not).

I thought about making onChange accept a diff object instead of a single key/value pair. It'd solve some of the issues, while still leaving the rest. Of course, we still have the problem of whether or not we should do a deep merge.

Both of these could will break backward compatibility, but it's something we may consider for v4.

3 replies

simplecommerce Jan 10, 2022
Author

Thanks for your follow-up and happy late new year!

For the moment I am using the modelTransform option in order to disable the dependent fields based on the values, it allows me to do what I want to achieve, the only issue I see so far is that I have to maintain the code differently, but other than that it works at the moment, don't know if its the right way.

Is there a difference between currently onChange for a single field and being able to update the whole model in a single call?
With the way its currently coded, is calling onChange on a single field more efficient than updating the whole model for a single field?

Reason I ask, is because if you are thinking about backwards compatibility issues, if updating a single field is more efficient doing it the current way, then you could maybe just add a new method to update the whole model for people that require this use case?

E.g.: If I need to update the state of a specific field only and not the whole model, I could call onChange but if I need to update the whole model because I have multiple fields I could call onChangeModel (I know its an existing method, but I am just using it as an example)

But if you say both would essentially do the same work and there are no difference in performance, then I suppose having a single method would work, maybe you could check the type, if its a string, you keep the old way to update a single field but if its a function you allow updating the whole model?

I am not sure I get the deep nested stuff because I don't know your whole code and all your use cases.

radekmie Jan 10, 2022

For the moment I am using the modelTransform option in order to disable the dependent fields based on the values, it allows me to do what I want to achieve, the only issue I see so far is that I have to maintain the code differently, but other than that it works at the moment, don't know if its the right way.

If you have any value-dependent logic, like disabled state or visibility, these should not be in the model at all, but rather calculated during the render phase and used as such. We often use custom hooks and AutoField components for doing that in a more general way (e.g., from the schema).

Is there a difference between currently onChange for a single field and being able to update the whole model in a single call?
With the way its currently coded, is calling onChange on a single field more efficient than updating the whole model for a single field?

Calling onChange multiple times is less effective than a possible implementation that would handle several updates at once. However, it's not that slower and shouldn't be a problem for most cases.

Reason I ask, is because if you are thinking about backwards compatibility issues, if updating a single field is more efficient doing it the current way, then you could maybe just add a new method to update the whole model for people that require this use case?

But such a new method would have to be wired up to all of the flows, like autosave or validation. Furthermore, it'd probably behave weird with onChange, as we'd either have to ignore it entirely in this case, or even recalculate all of the differences.

E.g.: If I need to update the state of a specific field only and not the whole model, I could call onChange but if I need to update the whole model because I have multiple fields I could call onChangeModel (I know its an existing method, but I am just using it as an example)

Technically, you can do it, by storing the model outside of your form. If you'd have a wrapper component with the model in its state, then it's up to you what kind of changes you're going to make. The only thing to make it work is to handle onChange correctly. (That's actually how AutoForm works.)

I am not sure I get the deep nested stuff because I don't know your whole code and all your use cases.

Don't worry about that. Discussions like this are needed for us to understand the need of other teams working with uniforms. For now, we'll need to brainstorm it internally, maybe something will come up. In the meantime, feel free to comment here further.

simplecommerce Jan 10, 2022
Author

If you have any value-dependent logic, like disabled state or visibility, these should not be in the model at all, but rather calculated during the render phase and used as such. We often use custom hooks and AutoField components for doing that in a more general way (e.g., from the schema).

Thanks! I think I am doing it ok then, in my modelTransform I have logic which checks for the dependent field and if its a certain value, I change the value of the other fields to false for example, but the disabled state is handle outside in the render.

At first I was handling the updating of the field values outside in the render using a useEffect based on the dependent fields, which would cause a re-render since I had to use setState in order to update the disabled field value because of my onChange calls.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

onChange multiple fields #1081

Uh oh!

{{title}}

Uh oh!

Replies: 2 comments 3 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Uh oh!

onChange multiple fields #1081

Uh oh!

simplecommerce Dec 23, 2021

Replies: 2 comments · 3 replies

Uh oh!

radekmie Mar 10, 2023

Uh oh!

radekmie Jan 10, 2022

Uh oh!

simplecommerce Jan 10, 2022 Author

Uh oh!

radekmie Jan 10, 2022

Uh oh!

simplecommerce Jan 10, 2022 Author

simplecommerce
Dec 23, 2021

Replies: 2 comments 3 replies

radekmie
Mar 10, 2023

radekmie
Jan 10, 2022

simplecommerce Jan 10, 2022
Author

simplecommerce Jan 10, 2022
Author