Regression introduced with x-for and sortableJS in V3

[seb3s]

Hi all,

I have the following code that works perfectly with alpine V2 but fails now with V3

alpine.meeting_steps = function(delegate, steps) { return {
    delegate: delegate,
    steps: steps,
    empty_step() {
        return {
            pos: 0,
            name: '',
            table_descr: '',
            duration: 5,
            modalities_id: []
        }
    },
    init() {0[
        this.steps = this.steps.length > 0 ? this.steps : Array(6).fill().map(this.empty_step)
        Sortable.create(this.$refs.table_body, {
            handle: '.drag_handle',
            onEnd: (Evt) => {
                let steps = this.steps,
                    move = steps.splice(Evt.oldIndex, 1)[0]
                steps.splice(Evt.newIndex, 0, move)
                this.steps = steps
            }
        })
    },

It is used with a :

< template x-for="(step, index) in steps" :key="index" >

After upgrading to V3, the internal "steps" data are still properly updated when rows are sorting (using sortable js library) but when alpine refreshes its x-for loop, it seems to introduce a shifting somewhere in the process. I mean the elements are redrawn with a shift of one place.

I've had a quick look at the for code, but this is a bit complicated for me ;-)
Thanks a lot for your hard work.

Sébastien.

[calebporzio]

Please provide a codepen reproduction of the issue you're describing - ideally in the simplest form possible - thanks!

[seb3s]

Hi Caleb,
Here we go with a minimalist example
https://codepen.io/seb3s/pen/bGWbpeo
Cheers,
Sébastien.

[seb3s]

Hello,
I've spent a lot of time trying to figure what's going on, but I currently don't master enough of the internals of alpinejs to be able to resolve my problem.
Maybe I need something like an "ignore" function to mutate the steps variable to stop DOM updates (as the movements are already done in the DOM because of the Sortable lib)
I'm stuck right now.
Sébastien.

[KevinBatdorf]

I checked your demo. You want to use slice instead of splice as splice will modify the original array and cause issues.

Here's a forked version of your demo with slice: https://codepen.io/KevinBatdorf/pen/bGWGwbP?editors=1010

[seb3s]

I've got other troubles now with other actions (add & delete actions not in the initial codepen) as _x_prevkeys are not properly updated when sorting data (because of Alpine.raw)
How can I force an update of these keys programmatically ?

[KevinBatdorf]

Hmm, I would think those keys would still be there as Alpine.raw isn't mutating the original object either.

Can you modify the demo with an example? I can take a look after that.

[seb3s]

Hum I'm fighting trying to reproduce what I've got.
The delete in the codepen seems to functions properly right now (but fails in my application: after moving some elements around, It can delete the wrong line).
But at least, some undesirable effect can be seen with the add button.
If nothing has moved, it pushes at the last place which is correct, but if you move the last row, it will start adding a row next to it instead of the end.
Hope this is clear enough ;-)

https://codepen.io/seb3s/pen/bGWbpeo

[KevinBatdorf]

Actually, that does seem like an opportunity for improvement in Alpine. I can maybe look into it this weekend. It stores the keys in the <template> tag as far as I can tell and not on the individual items. At first glance I'm not sure how to address that.

[seb3s]

Hello Kevin & Caleb,
I put a new codepen with what I've been obliged to do up until now to workaround the problem described.
https://codepen.io/seb3s/pen/ZEKGdxm
I can not use the 'index' variable in my code and I also had to use only ids to delete a row.

My hack consist of updating the _x_prevKeys on the template element to keep the order in sync with Sortable reordering.
Hope this helps to find a better solution,

Cheers, Sébastien.

[asika32764]

If you want to inject element after any others, it must do more hacks.

I provide a new example: https://codepen.io/asika32764/pen/KKvBGaY

[ampedweb]

This is an issue I'm currently fighting too, is there any more development on whether this might be tackled? 🙂

[elied]

I also ran into this issue. Aside from the workarounds listed above, here are two other options I found:

• After elements have been sorted, clear out the data array and use $nextTick() to rebuild it to the new order of the elements. This can cause a quick visual flicker after sorting.
• The sorting library I'm using allows me to 'cancel' the sort right before finalizing it, so I set up a handler that:
  • Grabs the new order of elements
  • Cancels the sort (to revert the changes to the DOM)
  • Updates the data array based on the new order we found (so Alpine will now update the DOM)

I like the second option a lot since it doesn't seem to have any visual artifacts, doesn't require changing Alpine's internal state, and still keeps Alpine as the source of truth for my data.

It would be nice to have a more official solution/plugin to handle this.

[ekwoka]

The issue is using the index as a key. Don't do that :)

[elied]

Maybe my situation was slightly different from the original issue posted here, but I am using x-for to create a list of DOM elements with an appropriate key.

I am also using an external library to allow reordering the elements, which works by literally moving each DOM element around. After the library reordered the elements, I still wanted my Alpine array to be updated to reflect what had happened in the DOM.

However, when I changed the array Alpine was getting confused because the list items were no longer in the order that they were the last time that Alpine rendered them and it would end up re-rendering them incorrectly.

[ekwoka]

Would you mind making a new thread with some replicatable code?

[Fisujon]

@elied Could you please give me the name of the plugin for sorting along with a code example?

[hugozap]

I found the same issue with Sortable and re setting _x_prevKeys after any external library changes DOM element positions solves it.
It would be a good idea to have a method like `notifyDOMChanged' that would automatically re calculate the _x_prevKeys, so users could just call it when external libraries change the order of elements without having to deal with internals like _x_prevKeys.

[dimitri-koenig]

See my solution here: #4157 (comment)