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

[Shantanu Tushar]

Hi,

On Thu, 30 Jun 2022 at 12:43, Federico Ferri
<federico.ferri.it at 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 at qt-project.org
> https://lists.qt-project.org/listinfo/interes