RowMeta index becomes stale when a row is prepended

[cyk]

Thanks for all the great work on this -- abstracting flexible tables ain't easy.

Currently, the rowMeta.index property is only updated whenever a node is accessed.

  objectAt(index) {
    // ...

    // Set the perceived index on the meta. It should be safe to do this here, since
    // the row will always be retrieved via `objectAt` before being used.
    set(meta, 'index', index);

    return result;
  }

This seems sufficient for most cases. However, it doesn't cover scenarios where a row is prepended (or, actually, any non-append operation). Because it shifts the indexes for subsequent rows with no change to the row objects. So there is usually no need to retrieve the row.

My specific use case is rendering row numbers from rowMeta.index. The workaround is to force object retrieval by binding to rows.length and re-rendering the relevant template section.

On Friday, I'm hoping to look into this a bit more and possibly come up with a solution. So any direction you can give would be much appreciated.

[pzuraq]

The best way to solve this will be making index a computed property. In order to figure out what the index of a row, we'll need to give the row metas enough context. If we store the offset of each row relative to its parent, we should be able to walk back up the row meta tree and add the offsets together to get the final offset.

Does that make sense?

[cyk]

Thanks for the direction. I'm working from this failing test. My initial thought is to compute and set the row meta's relative offset as part of the CollapseTreeNode.objectAt routine.

To confirm, this comment refers to it as a "perceived index." This means the meta index should not take into account collapsed nodes, right?

[pzuraq]

Actually I meant the opposite 😅perceived index meaning what we actually end up seeing rendered as the n-th row. So, given a particular collapse state in the tree, it flattens to real rows with a real index. The idea is that once we index into the tree (with its collapse state) it's basically an array, and everywhere else we treat it as if it were an array. If we ignored collapse state, it could throw calculations off quite a bit I think

[cyk]

After mulling it over a bit, here is what I've come up with.

Some pseudo code for calculating offsets and index:

Prev offset:

• If there is an offsetList, use it (this handles any nodes)
• If there is no offsetList but there are children, use their length (this handles any leaf nodes)
• If there is no offsetList or children, use parentRow.children indexOf (this handles the root)

Calculate index from a rowMeta:

while (this.prev) { someNumber += this.prevOffset }

We should be able to get that final offset (and index) of a row by adding the prevOffset meta until we can go no further.

Unfortunately, it seems that in order to get the necessary context we need to access the nodes directly which may be costly. Is there a more ideal way to get the offset information? Maybe this approach can be simplified by adding a computed to the node itself.

Does that sound right?

/cc @rondale-sc