Dimibe/sticky_grouped_list

RangeError (index): Invalid value: Not in inclusive range 0..1: 2

subhashDev11 opened this issue · 8 comments

when try to remove item with firestrore and streambuilder

Same issue, cannot find a workaround, it seems that StickyGroupedListView caches item count, and when the elements list changes (shrinks in this case), it tries to access list with old indexes, disregarding the fact that elements list has fewer items.

This issue happens only in edge case, when items in elements list fit on the screen without causing it to be scrollable.

Also I noticed, that it happens when reverse option is set to true, I think it has to do with the fact that itemCount in ScrollablePositionedList is calculated differently in this case (though it's a mere speculation).

Example:

Expanded(
        child: StickyGroupedListView<Message, DateTime>(
          reverse: true,
          elements: messages,
          order: StickyGroupedListOrder.ASC,
          groupBy: (Message m) {
            final DateTime dt =
                DateTime.fromMillisecondsSinceEpoch(m.creationDate * 1000);
            return DateTime(dt.year, dt.month, dt.day);
          },
          groupComparator: (DateTime value1, DateTime value2) =>
              value2.compareTo(value1),
          itemComparator: (Message m1, Message m2) {
            return m2.creationDate.compareTo(m1.creationDate);
          },
          separator: SizedBox(height: Dim.hm2),
          groupSeparatorBuilder: (Message message) {
            return Container(
              height: Dim.hm3,
              margin: EdgeInsets.symmetric(vertical: Dim.hm2),
              child: Stack(
                children: [
                  Align(
                    alignment: Alignment.center,
                    child: Divider(
                      thickness: 0.0,
                    ),
                  ),
                  Align(
                    // alignment: Alignment.center,
                    child: Container(
                      color: Theme.of(context).scaffoldBackgroundColor,
                      width: Dim.widthPercent(30),
                      child: Padding(
                        padding: const EdgeInsets.all(1.0),
                        child: Text(
                          DateFormatter.getVerboseDate(message.creationDate),
                          style: Theme.of(context).textTheme.subtitle1,
                          textAlign: TextAlign.center,
                        ),
                      ),
                    ),
                  ),
                ],
              ),
            );
          },
          itemBuilder: (_, Message message) {
            return ChangeNotifierProvider.value(
              value: message,
              child: MessageTile(message),
            );
          },
        ),
      )

Item removal happens higher in widget tree, and causes rebuild of stateless widget, in which StickyGroupedListView resides.

Sort of found a temporary, and far from ideal workaround, may be someone will find it helpful.
Instead of removing the item from source List, just flag them somehow, for example deleted = true;. And then in itemBuilder, just check the property and return an empty container or something like this. In this case the list will still hold the necessary items, and they all will be accessible by the old indices.

This is still an issue, did anyone found a solution?

@subhashDev11 @bobs4462 @mnarsely @mx1up @Manuelbaun I am having the same issue and along with that sometimes when u delete random values from the list, the list goes blank until a new child is added and the list is refreshed.

Did any of u found a solution?

I found a way around it, as the problem for me was the "reverse = true" variable, whenever there are changes on my list I switched the reverse to false to avoid blank screen and then switch back to true after those changes.

Same issue here - it is still occurring in current release. Unless the list is scrolled to the top (index 0?), then is a fatal RangeError thrown when rebuilding with itemBuilder.

Supporting an optional itemCount property may offer a fix.

2 years and a half later this is still happening. in our case, we have reverse set to the default value (false) and it also happens

any update on this?