Results 1 to 10 of 10

Thread: Grid state + reconfigure throws reusing stateIds warning

    You found a bug! We've classified it as EXTJS-21174 . We encourage you to continue the discussion and to find an acceptable workaround while we work on a permanent fix.
  1. #1
    Sencha Premium User
    Join Date
    Oct 2015
    Location
    Arvada, CO
    Posts
    76

    Default Grid state + reconfigure throws reusing stateIds warning

    In Ext JS 6, when using the reconfigure method with grid state, I get warnings about reusing stateIds. In Ext JS 5, I did not get this warning. Is this potentially a dangerous thing, or was there some sort of other change that shouldn't've affected this?
    [W] Ext.grid.header.Container attempted to reuse an existing id: Something

  2. #2
    Sencha - Support Team bjdurham85's Avatar
    Join Date
    Mar 2014
    Posts
    962

    Default

    Hi--,


    Hopefully you've been able to overcome this but if not let's see if we can get you sorted out.


    From what I can tell in your Fiddle the stateId names seem fine, however, I'm not seeing your state provider (i.e. cookie). Can you try adding a cookie provider and let us know if that resolved your issue?

    http://docs.sencha.com/extjs/6.0/6.0...CookieProvider

    Regards,
    Bryan

  3. #3
    Sencha Premium User
    Join Date
    Oct 2015
    Location
    Arvada, CO
    Posts
    76

    Default

    Quote Originally Posted by bjdurham85 View Post
    Hi--,


    Hopefully you've been able to overcome this but if not let's see if we can get you sorted out.


    From what I can tell in your Fiddle the stateId names seem fine, however, I'm not seeing your state provider (i.e. cookie). Can you try adding a cookie provider and let us know if that resolved your issue?

    http://docs.sencha.com/extjs/6.0/6.0...CookieProvider

    Regards,
    Bryan
    Hi Bryan,

    No, I haven't figured it out... added a LocalStorageProvider, still get the same error. Please see (updated) Fiddle in original post. Thanks!

  4. #4
    Sencha - Support Team bjdurham85's Avatar
    Join Date
    Mar 2014
    Posts
    962

    Default

    It looks like there is a bug reported for this, additionally another user submitted a potential override if you want to take a look.

    https://www.sencha.com/forum/showthr...mnsState-error


    Are you able to confirm it works in a nightly?

    Best!
    Bryan

  5. #5
    Sencha Premium User
    Join Date
    Oct 2015
    Location
    Arvada, CO
    Posts
    76

    Default

    Quote Originally Posted by bjdurham85 View Post
    It looks like there is a bug reported for this, additionally another user submitted a potential override if you want to take a look.

    https://www.sencha.com/forum/showthr...mnsState-error


    Are you able to confirm it works in a nightly?

    Best!
    Bryan
    Hi Bryan,

    No, that is not the same thing... I know this because I posted with my non-premium account in there, and I was the one that provided the override. Either way, I decided to test this against the 6.1 and 6.0 nightly and still I get the same warning.

  6. #6
    Sencha - Support Team bjdurham85's Avatar
    Join Date
    Mar 2014
    Posts
    962

    Default

    Sneaky

    I've gone ahead and created a bug in our tracking system with your latest info. Tested in 6.0/6.1 nightly and was able to reproduce.

    I've moved your thread to the bug specific forum so I can link to the issue.


    Best!
    Bryan

  7. #7
    Sencha Premium User
    Join Date
    Oct 2015
    Location
    Arvada, CO
    Posts
    76

    Default

    Quote Originally Posted by bjdurham85 View Post
    Sneaky
    That was a test

    Quote Originally Posted by bjdurham85 View Post
    I've gone ahead and created a bug in our tracking system with your latest info. Tested in 6.0/6.1 nightly and was able to reproduce.

    I've moved your thread to the bug specific forum so I can link to the issue.


    Best!
    Bryan
    Wonderful, thank you very much!

  8. #8
    Sencha Premium Member
    Join Date
    Oct 2015
    Posts
    22

    Default

    Did you find any workaround for this problem you could provide?

  9. #9
    Sencha Premium User
    Join Date
    Oct 2015
    Location
    Arvada, CO
    Posts
    76

    Default

    Quote Originally Posted by bellingham View Post
    Did you find any workaround for this problem you could provide?
    Sorry, fresh out of workarounds.

  10. #10
    Ext JS Premium Member tvanzoelen's Avatar
    Join Date
    Apr 2008
    Location
    Groningen - Netherlands
    Posts
    1,199

    Default

    Found this bug in 6.5.3

    Can we have a fix on this one?

    Seems quite obvious. On add stateId is used as index in _usedIDs, on removal headerId is used

    Code:
    onRemove: function(c, isDestroying) {
            var me = this,
                ownerCt = me.ownerCt;
    
            me.callParent([c, isDestroying]);
    
            //<debug>
            if (!me._usedIDs) {
                me._usedIDs = {};
            }
            delete me._usedIDs[c.headerId];
            //</debug>
    
            if (!me.destroying) {
                // isDDMoveInGrid flag set by Ext.grid.header.DropZone when moving into another container *within the same grid*.
                // This stops header change processing from being executed twice, once on remove and then on the subsequent add.
                if (!me.getRootHeaderCt().isDDMoveInGrid) {
                    me.onHeadersChanged(c, false);
                }
    
                if (me.maybeContinueRemove()) {
                    // Detach the header from the DOM here. Since we're removing and destroying the container,
                    // the inner DOM may get overwritten, since Container::deatchOnRemove gets processed after
                    // onRemove.
                    if (c.rendered) {
                        c.detachFromBody();
                    }
                    
                    // If we don't have any items left and we're a group, remove ourselves.
                    // This will cascade up if necessary. DO NOT destroy ourselves here,
                    // we have to defer that until all moves are done and events are fired.
                    me.destroyAfterRemoving = true;
                    
                    Ext.suspendLayouts();
                    ownerCt.remove(me, false);
                    Ext.resumeLayouts(true);
                }
            }
        },

    ---> delete me._usedIDs[c.headerId];

    But since usedIDs is only used for your internal <debugging> , I suggest you delete that hash completely.

    Work around would be, to set usedIDs to null or {} before reconfiguring.

Similar Threads

  1. Apply state after grid reconfigure
    By famainacc in forum Ext 5: Q&A
    Replies: 9
    Last Post: 30 Jul 2019, 9:47 PM
  2. Replies: 3
    Last Post: 27 Aug 2014, 12:43 AM
  3. Replies: 3
    Last Post: 30 Aug 2013, 4:50 AM
  4. Replies: 1
    Last Post: 4 Feb 2013, 7:09 AM
  5. Applying state on Grid Reconfigure
    By vasanthatextjs in forum Ext: Q&A
    Replies: 3
    Last Post: 18 Sep 2012, 4:01 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •