v-for not respecting array order

[TomS-]

Having an issue with v-for is not respecting the order of the array but is randomly ordering however it wants.

const venues = PetiteVue.reactive({
    items: [],
    search: "",
    order: "a-z",
    get filtered() {
      let filtered = this.items.filter(item => item.title.toLowerCase().includes(this.search.toLowerCase()));
      filtered = filtered.sort((a, b) => {
        if(this.order == "a-z") {
          if(a.title.toLowerCase() > b.title.toLowerCase()) return -1;
          if(a.title.toLowerCase() < b.title.toLowerCase()) return 1;
          return 0;
        } else if(this.order == "latest") {
          return a.modified - b.modified; 
        }
      });

      console.log( filtered );

      return filtered;
    }
  });

  PetiteVue.createApp({ venues }).mount();

Filtered is returning:

But the actual order is being displayed as:

Does anyone know how to fix this?

[sqllyw]

based on your fragment of code, here is a working version, it shows the array in the order you want:
https://jsfiddle.net/sv9oLx0y/

[TomS-]

Thanks for this, sorry I should have mentioned. It works correctly until I search. I have updated your jsfiddle with the search function:
https://jsfiddle.net/tzwb4ecv/

If you type something in search, you will see when it's back to empty it doesn't respect the order of the array you see in console.log.

[sqllyw]

Got your point, the official grid.html example has similar issue:

https://jsfiddle.net/gumde7nr/

first pass, you got: Bruce Lee, Chuck Norris, Jackie Chan, Jet Li
type B, then back space, you got Bruce Lee, Jet Li, Jackie Chan, Chuck Norris

A intended behaviour or a bug?

[TomS-]

I would assume that this is a bug, but I have no idea what's causing it to not respect the actual array order. It might be some form of caching?

[nooooooom]

I think an error occurred when reusing components, I tried to fix it, it looks good at present work.(nooooooom@e2404f6)

[go4cas]

@nooooooom, I am having the same issue. Any idea how/when your changes could be reviewed and merged?

[nooooooom]

I don’t know, but just now I discovered that this sorting algorithm has another problem besides the nextBlock lookup error, and I’m fixing it.

[lumlumi]

This bug happen only on array update.

If we take a look in v-for implementation, this is v-for initilisation.

  if (!mounted) {
      blocks = childCtxs.map((s) => mountBlock(s, anchor))
      mounted = true
    } 

When updating, you can see below that the index is in reverse order and therefore the html mount is done in reverse. It explains the reverse order of the display.

      let i = childCtxs.length
      while (i--) {
        const childCtx = childCtxs[i]
        const oldIndex = prevKeyToIndexMap.get(childCtx.key)
        const next = childCtxs[i + 1]
        const nextBlockOldIndex = next && prevKeyToIndexMap.get(next.key)
        const nextBlock =
          nextBlockOldIndex == null ? undefined : blocks[nextBlockOldIndex]
        if (oldIndex == null) {
          // new
          nextBlocks[i] = mountBlock(
            childCtx,
            nextBlock ? nextBlock.el : anchor
          )
        } else {
          // update
          const block = (nextBlocks[i] = blocks[oldIndex])
          Object.assign(block.ctx.scope, childCtx.scope)
          if (oldIndex !== i) {
            // moved
            if (blocks[oldIndex + 1] !== nextBlock) {
              block.insert(parent, nextBlock ? nextBlock.el : anchor)
            }
          }
        }
      }

I made a dirty fix to verify this and it's working correctly. Note that this does not solve the problem with the grid example, which is another issue.

[lumlumi]

There is the fix : #78. Finally it solve grid example issue.

[Emory-M]

Many pr waiting for, quick fix the bug in min js file, replace let n=b.length;for(;n--;) with for(let n=0;n<b.length;n++) and self-hosted it.

[nooooooom]

I think it's not just this kind of problem, because of performance optimization, it will cause the data to be inconsistent with the UI that is finally displayed. You can compare the shuffled array with the UI.
Even's approach is no problem, but there is a situation that when two parallel data move forward, the data comparison will be problematic.

[nooooooom]

Reverse in response to insertBefore, it is compared to the benefits of positive sequence is more convenient to find the anchor, and the ability to quickly know whether they should move even in the case of index changes.I have repaired it on the basis of original thinking, It works now (nooooooom@cc29958)

[lumlumi]

yes you are right. Can you create PR to trace this ?

[nooooooom]

How about this(#79).

[TomS-]

This has been pushed to live now thanks to @nooooooom for the PR.