Model: reason for iterating over all bindings in "checkUpdate"?
See original GitHub issueUI5 offers some very powerful binding concepts. One thing I’m trying to understand though is why models are required to iterate over all of their bindings in checkUpdate
after calling setProperty
with a specific path.
URL (minimal example if possible):
https://jsbin.com/lepecom/edit?js,output
Steps to reproduce the problem:
- After opening the sample above, set a breakpoint somewhere at https://github.com/SAP/openui5/blob/0ecc4da44b3aae7beae2f79b60f178266c82cf0d/src/sap.ui.core/src/sap/ui/model/Model.js#L892-L895
- Type some text in the input field and press <kbd>Enter</kbd> to trigger
setProperty("/A", ...)
and eventuallycheckUpdate
.
You can see that aBindings
contains all binding instances that were created by that model. It iterates over all of them although only bindings that are associated with the path "/A"
would be needed to get notified about the change* or not?
In which cases would other bindings with different paths need to be notified too even though the change took place completely somewhere else?
* The same can be observed with ODataModel. A typical ODataModel holds around 1k to 3k binding instances throughout the lifecycle of the application. If one field changes, the model iterates over all 3k bindings and performs deepEqual
each time.
Issue Analytics
- State:
- Created 4 years ago
- Comments:15 (14 by maintainers)
Top GitHub Comments
@goligo like everybody else we are constantly optimizing our application and we are replacing slow parts by more efficient parts. I even gave a talk about optimizing firori aps 2017 on the TechEd: https://de.slideshare.net/ManuelB86/optimizing-an-sap-fiori-application-based-on-a-real-world-exampl Nevertheless we are measuring that binding updates are quite often a slow part and we hope that in the next releases of UI5 optimizations are applied.
I can fully understand that there are internal priorities that you can’t change but I try to support you as best as I can.
@goligo yes when the user enters a value in a field it might happen that he has to wait 0.2 seconds when we update a lot of fields maybe even more. We are already using the bAsync parameter for setProperty in some cases and it already helped a lot. From around 20 seconds waiting time to 2 seconds but I am convinced that the way how bindings are updated could be improved.