[Interest] Why Repeater.count increases before the item is actually created?

[Federico Ferri]

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.

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20220630/b55e978b/attachment.htm>