Hi, On Thu, 30 Jun 2022 at 12:43, Federico Ferri <federico.ferri...@gmail.com> wrote: > > My real-use case is too complex, but consider the simple scenario of a UI > control that features an array of whatever controls, say checkboxes, and > computes an aggregate property, i.e. a function of all the checkboxes states > f(repeater.itemAt(0).checked, repeater.itemAt(1).checked, ...). > > So I don't think this is violating the golden model-view separation rule. It > is a UI-only repeater, the Repeater's model it's just an integer, and could > be even constant. The aggregate property value (result of f()) is what is > exchanged with the business-logic model. > > But depending on the complexity of f(), not always it is possible to do it > without a for-loop iterating over the Repeater's delegates. Sometimes it is > possible to invert the logic, and have each delegate do its small bit of > computation, but that considerably increases the complexity, with respect to > the top-down for-loop solution.
That is basically what I would have recommended (and have done in the past). Having the delegates update the information in a global object / property is quite reliable (well, as long as you ensure that what they are doing is idempotent). > > Hence sometimes one would still prefer the for-loop approach. But if the > count property (which I believe it's also there to work together with the > .itemAt() method, and not just for showing a count to the user) was emitted > in a more sensible moment, one would not need redundant null-checks at what > .itemAt() returns. If you absolutely have to do it, maybe schedule the actual calculation to the next iteration of the event loop? Basically inside your onXXXChanged handler, start a 0-interval single-shot Timer and do your calculation there? -- Shantanu Tushar shantanu.io > > An additional consideration: is the for-loop approach relying on signal > order? No, eventually there will be more property changes and the application > will settle to the final (correct) state. > It's just that the current order of signals causes more transitory states, > some of which result in a JS error if we don't add those redundant > null-checks. > > -- > Federico Ferri > _______________________________________________ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interes _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
