1. #1
    Sencha User
    Join Date
    Feb 2012
    Posts
    21
    Vote Rating
    2
    alexmipego is on a distinguished road

      0  

    Default Store and MixedCollection Remove event out of order

    Store and MixedCollection Remove event out of order


    Before 4.2 beta the remove event fired by the Store -> ... -> AbstractMixedCollection was fire after the object was actually removed but now the list is actually in a inconsistent state.

    The code that fires the event is located inside the removeAt method of the AbstractMixedCollection and the event is being fired inside a loop that is attempting to delete the map(ped) keys in the collection. At this point if you use a getCount() or access (directly or indirectly) the items property of the Store/Collection you'll get the results as if the item still existed, which defeats the puporse of this event.

  2. #2
    Sencha - Ext JS Dev Team evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    17,004
    Vote Rating
    650
    evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute evant has a reputation beyond repute

      0  

    Default


    There is an issue with the MixedCollection where it won't update the state/count during the remove event, this will be fixed. However, if you're accessing the data property on the store, this will not change. The reasoning behind it is that it's a lot more performant to remove a whole bunch of items at once and then update the collection. Buffering stores and trees do this quite a lot, so the underlying collection has a flag set so that it performs a "fast remove", since the store doesn't really care about the remove event of the underlying data collection.

    FYI, the ticket for fixing just the collection is EXTJSIV-8244.
    Evan Trimboli
    Sencha Developer
    Twitter - @evantrimboli
    Don't be afraid of the source code!

  3. #3
    Sencha User
    Join Date
    Feb 2012
    Posts
    21
    Vote Rating
    2
    alexmipego is on a distinguished road

      0  

    Default


    I understand that code and what it's trying to do, namely the speed optimations. However, if I wanted to listen to bulk changes only I would subscribe the bulkadd/bulkremove events instead.

    In my particular case I patched the code so that I fire the event for each item returned by the splice calls. Although it solves MY problem, there's still a issue in cases people need to know only the particular item has been removed.

  4. #4
    Sencha User
    Join Date
    Feb 2012
    Posts
    21
    Vote Rating
    2
    alexmipego is on a distinguished road

      0  

    Default


    Allow me to improve on what I said above.

    Previously the removeAt method was defined as seen here: http://docs.sencha.com/ext-js/4-1/source/AbstractMixedCollection.html#Ext-util-AbstractMixedCollection-method-removeAt

    That is clearly a method that deletes 1 item, nothing more. The new version: http://cdn.sencha.com/ext/beta/4.2.0.265/docs/source/AbstractMixedCollection.html#Ext-util-AbstractMixedCollection-method-removeAt

    Attempts to allow for the removal of more than a single item and implements a welcome optimization for that case. But in the process is breaking a needed feature.

    I would suggest moving the new removeAt method into another method called, for instance, bulkRemove. If you do that and patch the places that call the new version with that additional argument, then you would be able to take advantage of the optimizations while not breaking any code. Additionally, if some part of the optimizations can still be ported to the old version there would be little problem since there's only 1 record and 1 event being fired.

Thread Participants: 1