Does the sequence of updated properties in @NotifyChange matter?

answered 2022-06-13 11:27:19 +0800

MDuchemin
2560 ● 1 ● 6

Hi there,

The order of updated properties in a notify change usually doesn't matter, but it can in specific cases.

The key is that properties are processed sequentially and thus put client responses commands in the queue sequentially, so if you are updating multiple properties, and components are state-dependent on more than one of these properties, the end result might be different depending on the order.

For example, assuming you have an input with hint such as a combobox, and you have both a model attribute and a selectedItem attribute bound to some of your viewModel's properties.

<combobox model="@load(vm.model)" selectedItem="@load(vm.selItem)"/>

In this case, the order of operation will matter. This is because both the model property and the selectedItem property control selection on the combobox.

The model (usually a ListModelList) has a selection field, which contains "the list of selected items in the model". If you are passing a standard Java List, ZK will automatically wrap it into a ListModel, so there is no difference between providing a List<mydatabean> or a ListModelList<mydatabean>.

When the client-side widget of the combobox receives the set model command from the response, it also sets the selection that comes with the model object (or the empty selection if model holds no selection).

When the client-side widget of the combobox receives the set selectedItem command, it will also update selection.

So you have 2 possible scenario in this case:

• model then selectedItem: The client-side widget will first update the model (change the content of the component), then perform selectedItem and set the selection to the expected target.

• selectedItem then model The client-side widget will first set the selection on the old dataset before setModel is invoked. Then the client will set the model, and loose the selection state that was previously passed.