Refreshing Sort Order Fields after Deletion of 1 or more rows?

Good day friends. I am guessing this is something the pros have solved 100 times over. I’ve wrestled with it and suspect its a recursive flow, I just can’t wrap my head around it just yet.

I have a data type with a field for sort order. Users can dynamically add new rows of data, and dynamically re-order them. Sort order is calculated as datatype:count +1 every time a new row is added).

Everything works fine (add, re-order/sort) until a delete action happens in any row that isn’t the last.

Item1 - sort 1
Item 2 - sort 2
Item 3 - sort 3
Item 4 - Sort 4

If a user deletes Item 2 - all is well, and everything is in the proper order, but the user has to basically tap Item 1 or 3 a couple of times to re-order them given the gap, annoying but not the primary problem. .
Item 1 - sort 1
Item 3 sort 3
Item 4 sort 4

But if they then add a new row (remember it is count+1 to determine the next sort# in the DB), their sort and ability to re-sort is jumbled and I have two items both with the sort value of 4 .

Item 1 - sort 1
Item 3 sort 3
Item 4 sort 4
New row: Item 5 sort 4 (the preceding 3 items +1)

What I think I need is some form of recursive or another workflow, which re-writes all of the Sort values whenever a row is deleted (and quickly, before a user adds a new row or re-orders the remaining sort values again)

Without too much pain, does anyone have this math already on a napkin pinned to their corkboard that can be shared?

1 Like

Hi there, @K.T… if I understand your post correctly, you need to make changes to a list of things when a user deletes an item, and you need to make changes to the list before the item is deleted because you will use the soon-to-be-deleted item’s sort value to define the list.

When an item is deleted, make changes to a list of things where the sort values of the items are greater than the sort value of the item that is being deleted, and the change to make to those items is to subtract 1 from their sort values. After the changes are made, delete the selected item, and you should be good to go.

Note that you might (probably) want to use a custom event to make changes to the list to make sure that process finishes before the selected item is deleted.

Hope this helps.


Edit: I just realized the title of the post mentions deleting 1 or more rows, and the “or more” part definitely adds a wrinkle. The suggestion I made above still holds, but I think you would have to make changes to the list (now lists) of things in a recursive backend workflow so you can pass a list of sort values (the sort values of the items that are being deleted) to the backend workflow. If you pass the list of sort values to the backend workflow in descending order, you can use the values one at a time (starting with the first item, which will be the max value in the list) to do what I described above. Then, the last step in the backend workflow will call the workflow again and remove the first item from the list of sort values so it can use the new first item to define the new list of items to change.

Another edit: in case it helps, I made an example that I believe should work (the example is a bit different than what I described above), but I can’t test it because my sandbox app is on the free plan. For the example, I am storing the items that will be deleted in a custom state called selected items on the index page. Here is what the backend workflow looks like.

When a delete button is clicked, I run the backend workflow like this.

The actions in the backend workflow look like this.


@mikeloc didn’t want to sleep on a thank you for the detailed reply.

Truly, way above and beyond. I’ll give it a try as soon as I get the kids to sleep tonight (i.e my office hours!)

At a minimum, the list solution should work, if I speed bump and only allow 1 delete at a time (I feel silly for not figuring that out), but learn the gold standard approach as well for the optimal solution.

Again truly appreciate the time invested.

Best regards

1 Like

This topic was automatically closed after 70 days. New replies are no longer allowed.