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

Shantanu Tushar shaan7in at gmail.com
Thu Jun 30 11:20:48 CEST 2022


Although I haven't looked deep inside the Repeater implementation to
answer _why_ you see the behavior described, I think you already
answered the question of why you are facing difficulty. It is not very
declarative to expect these things to happen in a certain order.
Especially when it comes to delegates, it is generally a bad idea to
get them to "talk" to each other. Usually delegates should be
independent of each other and perform actions by talking to the model,
or maybe a controller object in C++ (or in QML, if it's quite simple).
This is not specific to Repeater, it applies to ListView and friends
as well. In this particular example, Repeater.count is mostly there so
that you can show a count of items to your user, not so much for
business logic.

Maybe you can share some details about what exactly your delegates
want to do by accessing the other items in the Repeater? There might
be a better way of doing that instead of relying on creation order /
property update order.

On Thu, 30 Jun 2022 at 11:02, Federico Ferri
<federico.ferri.it at gmail.com> wrote:
> I have some places in my QML code where an Item created by Repeater needs to interact with the other Items managed by the Repeater. So it does something like:
>     onXXXChanged: {
>         for(var i = 0; i < repeater.count; i++) {
>             var item = repeater.itemAt(i)
>             ...
>         }
>     }
> in reaction to various events.
> However itemAt() -quite unpredictably, meaning sometimes it doesn't happen- can return null (usually on the last item). Sure the docs say that itemAt could return null if items does not exist, and that count can be higher than the actual number of items during the process of instantiating items, so it is kind of to be expected.
> The solution seems to be to check for null before proceeding. It would also be possible to bind to itemAdded/itemRemoved signals of Repeater, but not practical in my case.
> However, wouldn't it be more useful to change count only when the last item is actually available? (binding to count allows for more declarative code; binding to signals allows reactive code, which I find somewhat inferior to declarative code; when reading this consideration please disregard my code snippet above, which is not particularly declarative ^.^...)
> Is there a "declarative" reason for behaving the way it behaves now?
> Cheers,
> Federico Ferri
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest

Shantanu Tushar

More information about the Interest mailing list