That’s a pretty complicated derive use-case that’s only viable if it doesn’t trigger a rerender of the entire list
did you ever get an answer about can-derive being updated for 3.0?
I think there are maybe alternate approaches that 3.0 offers though
so if you’re replcing with a subset, you should just get
remove events
I could rebuild my stuff to just virtualize the set params, couple it w/ can-stream to debounce, then return new Lists from the dynamic set
Man that’s literally been on my wish list for like 3 years
That’s beautiful work :D
can-view-live makes my use-case for can-derive solveable just with can-connect alone
part of what I said isn’t exactly true I guess, you probably won’t get only remove events
Which is what I want ^^
out of curiousity I was testing it out
and you might get only remove events… but you might not
nevertheless, you get events based off the diff
@phillipskevin I saw your example and those are great examples. On knockoutjs you could define the way this kind of “computed” attributes were updated, can you do that in can?
this kind of thing is what I use most often
get active(){ return this.filter({complete: false}); }, get complete(){ return this.filter({complete: true}); }, get allComplete(){ return this.length === this.complete.length; }
can-stream does that
using an asynchronous getter
but I would wait until you run into an issue like that before doing that kind of thing
most of the time, you should let the event batching system take care of that kind of thing for you
@Bajix wouldn’t
this.__listSet tell can-connect that it’s the same list?
for now I’m going to take your word for it :smile:
That’s how it works ^
Or at least that would clarify