knockout-fast-foreach
knockout-fast-foreach copied to clipboard
brianmhunt
Add `$isFirst`, `$isLast`
@cervengoc A truthy/falsy test e.g. $atIndex(4) returns true if the item is at index 4. I had it in my mind that this could be O(1), but I'm not entirely convinced I'm right. :grin:
Well I don't know. At first glance it seems to me that any solution which depends on individual index values other than first or last leads to unavoidable index maintenance in one way or another. And on the other hand, personally I don't like the $atIndex function, I think it's not usable too well and a bit counter-intuitive (one would expect it to be an observable like all others). But that's really kind of a personal preference.
Anyway, please see my comment at the original topic too.
@cervengoc Yeah, I'm with you. I think it'll just be $isFirst and $isLast
I have just come across a need for isLast but also an isNotLast. Is it worth adding:
- isNotFirst
- isNotLast
- isNotFirstOrLast (a little long and I don't have a need but why not?)
They should all still be O(1) ...or not?
@AdamWillden They should all be O(1); the isNotLast & isNotFirst are IMHO expressed better as !$isLast and !$isFirst respectively. I.e. there should be no need for property values for these as they can be computed on the fly. At least, that's my thinking. :smile: What do you think?
Possibly coming from ignorance, but are $isLast and $isFirst observables or values? If they're observables then !$isLast wouldn't work but !$isLast() would. I see this as being a cousin of KO including both if and ifnot bindings. Is there any drawback to having to evaluate !isLast()
Thanks @IanYates – Yes, !isLast() is the right syntax. :) It should be an observable (though may in the implementation end up being an opaque defineProperty).
!isLast() ends up being an "implied computed', just as isNotLast would likely be– though with isNotLast there's an extra layer.
I'm not totally averse to adding isNotLast/First, but I don't want to clutter up the API with things that are better written with a simple negation operator.
No problem @brianmhunt. Just floating the idea but what you say makes sense. I think it'd be nicer as an opaque defineProperty