Question about store `range` update API
I've been trying to update the docs for the
store
page and I noticed an API decision I found surprising.
The path syntax for specifying a range of indices to update in an array { from: 3, to: 7 }
is inclusive for both start and end.
Most similar JS APIs I can think of (.slice
for example) are start inclusive, end exclusive.
Does anyone know why the index range API works this way? I thought it might be worth calling out in the docs, but I'm also just curious even if it's not.6 Replies
What does inclusive mean in this context?
I think it means that it will target index 3 and 7 and everything in between
while
.slice
will target index 3 and everything until 7
Unless you mean something else π
Yes, that's exactly right.
[3, 7]
updates 3, 4, 5, 6, and 7, whereas something like .slice
would take 3, 4, 5, and 6.
As a concrete example of what that means, if you update { from: x, to: array.length }
you get TypeError: Cannot read properties of undefined
since it goes one past the final index of the array.Gotcha! Thanks for the explanation!
It's probably worth noting that the spec uses the parameter names
start
and end
for slice
.
end
is considered the index directly following the last inclusive index. Also slice
is a copying operation.
splice
is the mutating operation and it used start
and deleteCount
, not start, end
and therefore side stepping the entire half-open, inclusive debate; opting instead to be clear about the (maximum) number of elements that will be deleted.
So fortunately the names from
and to
were used instead.
The existence of the optional by
property probably tipped the balance in favour of the inclusive range because it focuses entirely on the elements to be impacted rather than having to figure out βthe first index that won't be impacted (anymore)β
I see, thanks for the info!