Different onReorder index args compared to ReorderableListView

[Ross Llewallyn]

I may be misunderstanding things, but I want to better understand and possibly report a bug or design difference.

In all of these examples, assume there are 3+ list items.

ReorderableGridView

• I drag the first item to the second place. The index arguments I get are 0 and 1.
• I drag the second item to the first place (the reverse), the index arguments I get are 1 and 0.

ReorderableListView

• I drag the first item to the second place. The index arguments I get are 0 and 2. 😲
• I drag the second item to the first place (the reverse), the index arguments I get are 1 and 0.

Discussion

Is this an intentional difference? I was hoping to easily swap these 2 widgets, but now I have to change how the indices are interpreted.

I don't believe I've done anything fancy or unique with my widgets, but please let me know if this is not what others experience.

[Cas van Luijtelaar]

Interesting problem, I can replicate it.

This is not an intentional difference, and although this library tries to mimic the listview implementation as closely as possible. I can't immediatly see a reason why the reorderableListView would provide index 2. But I feel as the ReorderableListView has the correct, simplest implementation (see example). So this might be a question for the flutter team for them to clarify why, or if it is a bug

[Ross Llewallyn]

I can't immediatly see a reason why the reorderableListView would provide index 2.

I do believe there is a reason for the asymmetry depending on which way you drag. When you move an item from earlier in a list to a later point, it gets a little tricky, since every item after it can be considered either in their original index or in index - 1. I think your plugin assumes one and Flutter the other.

My previous implementation for native Flutter widget worked fine because I designed for that. I would take these steps (but simplify if the item is dragged to the end):

1. Get the item being moved
2. Get the item at the target index
3. Remove the item from step 1
4. Find the index of the item from step 2 (maybe it changed, maybe not)
5. Insert item from step 1 at index from step 4

Not sure if this is helpful; I just wanted to share how I've worked with Flutter's way in case that makes sense. Ultimately I'm not sure what the right approach should be. I'm certainly curious to hear an explanation from Flutter themselves.

[Cas van Luijtelaar]

yes my package calculates the new index pre-move which in my opinion results in a cleaner implementation. But of course that is subjective.

  void _onReorder(int oldIndex, int newIndex) {
    setState(() {
      final item = items.removeAt(oldIndex);
      items.insert(newIndex, item);
    });
  }

[olof-dev]

flutter/flutter#127901
Please thumbs up 👍

[Cas van Luijtelaar]

so it is an existing flutter issue, I will consider my implementation as correct! will close this one and you can followup there