Success! Looks like we've fixed this one. According to our records the fix was applied for
EXTJS-13702
in
5.0.1.
-
Ext.get() throws errors if the element has the same id as a recently removed element
Trying to upgrade a few parts of our codebase now to Ext 5. We see this warning/crash a bit:
Code:
Uncaught Error: DOM element with id schedulergrid-1009-timelineview-2 in Element cache is not the same as element in the DOM. Make sure to clean up Element instances using destroy()
Any explanation of what's going on, new Element caching in place compared to Ext 4?
-
Presumably you've got something like this happening:
Code:
document.body.innerHTML = '<div id="foo"></div>';
Ext.get('foo');
document.body.innerHTML = '<div id="foo"></div>';
Ext.get('foo');
Twitter - @evantrimboli
Former Sencha framework engineer, available for consulting.
As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.
-
Ehm, this is a bug then? Docs: http://docs.sencha.com/ext/5.0.0/api...Ext-method-get
"Uses simple caching to consistently return the same object. Automatically fixes if an object was recreated with the same id via AJAX or DOM."
The caching is new in 5?
-
It's a debug only check, perhaps it could be a warning. But it's poor practice to be overwriting elements in the DOM that have already pulled in via Ext.get().
The caching has existed since at least 4.x.
Twitter - @evantrimboli
Former Sencha framework engineer, available for consulting.
As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.
-
Well it's a hard crash now. But the check has changed, had no issues with this in 4.x... Thoughts?
In our case, we refresh a grid row which contains custom elements - with id's that may or may not have been grabbed using Ext.get before. Are you saying before every row update we should purge your cache?
-
It could be a bug, but it's basically checking if you have 2 nodes with the same id in the DOM. Is it possible to get a test case and/or a call stack?
Twitter - @evantrimboli
Former Sencha framework engineer, available for consulting.
As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.
-
Using Evan's code:
I only get a console.warn:
[W] Stale Element with id foo found in Element cache. Make sure to clean up Element instances using destroy()
-
Test case and fiddle - crash in latest nightly sources (no crash in latest public beta).
Code:
var grid = new Ext.grid.Panel({
store : new Ext.data.Store({
fields : ['a', 'b'],
data : [
[1, 2]
]
}),
height : 200,
width : 300,
columns : [
{
renderer : function () {
return '<div id="foo">div with id</div>'
},
locked : true
},
{
renderer : function () {
return 'some data'
}
}
]
});
grid.render(Ext.getBody());
Ext.get('foo')
grid.view.refresh();
// Hard crash
Ext.get('foo')
Few questions:
1. Is this considered 'wrongful' use of your Grid / Element API?
2. Can we somehow opt out of the caching, or it's checks?
3. This was fine in Ext 4.x, is there an override to get back the old way?
-
I've got same problem with calendar rendered in grid where cells are generated trough DomHelper with unique id. After data are loaded / grid is refreshed, grid crash with error:
Code:
DOM element with id all_day_0 in Element cache is not the same as element in the DOM. Make sure to clean up Element instances using destroy()
. As Mats wrote, everything works well in latest Ext 4.2
-
Anything new on this? Nothing changed in current release.