You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is something that a couple of people have suggested to me previously, so it is something I'd like to address, but it isn't quite as simple as it first appears.
There isn't an underlying array that'd be equivalent to the array used by the native JS methods.
For example, if you consider this template:
<ChildComponent><divv-for="i in 3">{{ i }}</div><hr><pv-for="i in 3">{{ i }}</p></ChildComponent>
Inside ChildComponent, the slot will yield VNodes with a structure like this:
Here I've used arrays to represent the nested fragment VNodes.
The structure is a tree, rather than a flat array. That structure makes it more difficult to work with, but it's also important for Vue to be able to perform updates accurately.
The iterators in vue-vnode-utils try to ease the pain of walking and manipulating that tree, but without actually flattening it. So the tree above will behave as though it is iterating a flat array, like:
But that array doesn't actually exist, and it would be extra work to create it and pass it to the iterators.
The concept of an index isn't well-defined either. For iterating a tree structure there are two distinct concepts: count and path. The count would just increment by 1 for each node passed to the callback, whereas the path would indicate the position within the tree. Using the example above, the first <p> node would have a count of 4 and a path of [2, 0].
Further complicating matters, there are other pieces of information that someone might want, such as access to the parent node.
As it wasn't clear what extra information should be passed, I decided to stick to just the VNode.
Implementing a count is relatively straightforward to do externally, e.g. See the accordion example at https://skirtles-code.github.io/vue-vnode-utils/examples.html#adding-component-v-model. That works fine for cases that need the position from the beginning of the iteration, but less well in cases that need to know the position from the end of iteration (as the total count isn't known).
I've got some ideas for how to proceed here, trying to add access to some of this 'iteration meta' without negatively impacting performance or bundle size, but I'd be interested to gather any further thoughts you might have on use cases first.
Presently, the callbacks passed to iterators receive only one argument: vnode.
It'd be very helpful if these all received the standard Javascript arguments, namely: (item, index, array)
See: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map#callbackfn
One usage example might be for addProps where you might want to conditionally apply a prop dependent on where it is in the array.
The text was updated successfully, but these errors were encountered: