View Full Version : [OPEN] ListFilter 'active' config loading from remote store when 'options' have been defined

29 Jul 2015, 6:19 AM

(Not Complete) https://fiddle.sencha.com/#fiddle/r9v

Ext version tested:

Ext 6.00
Browser versions tested against:

Chrome 44.0.2403.107 m
DOCTYPE tested against:


We have a custom PagingWebSocketStore extending Store which is backed by a MemoryProxy with server side paging, sorting and filtering rendering into a simple grid. The Store is populated by callbacks on the 'filterchange' 'sort' events and also by overriding the loadPage, nextPage function which call the backend using Ajax or respond to WebSocket pushes. One of the columns in the grid has a list filter with pre-defined option values eg.

filter: {
type: 'list',
options: [1, 2, 4]

When I select the list filter via the UI the 'onfilterchange' callback is fired which calls our backend and tries to populate the Store using loadRawData(data). When this occurs I'm seeing an error occur in the List.js filter. Attached below:

Uncaught TypeError: Cannot read property 'items' of nullExt.define.getOptionsFromStore @ List.js:483Ext.define.createListStore @ List.js:291Ext.define.bindMenuStore @ List.js:271Ext.define.onDataChanged @ List.js:524fire @ Event.js:413doFireEvent @ Observable.js:780prototype.doFireEvent @ EventDomain.js:293fireEventArgs @ Observable.js:620fireEvent @ Observable.js:573Ext.define.loadRecords @ Store.js:1044Ext.define.loadRawData @ Store.js:993getNotificationsService.updateFilter.then.success @ NotificationsStore.js:213Ext.Function.ExtFunction.bind.method @ Function.js:148(anonymous function) @ deft.js:8g

For some reason it appears despite the ListFilter having it's options populated locally via the 'options' config it is still registering itself for 'onDataChanged' events causing the above error.

Digging a bit deeper into the source I can see in List.js (Ext.grid.filters.filter.List) at line 340 we register the onDataChanged callback on the refresh/add etc events on the Store. Is this correct? I'm using a static list of options so we shouldn't need to listen for changes in the underlying store? If I comment line 340 out everything seams to work....

Maybe I've missed something or in all our customization we've broken something but at it's most basic it doesn't seam right to listen for events on the store if we are using a local list of options.

It's all a little complex to setup a fiddle for as it's mostly bespoke code using WebSockets etc which I'm not even sure how to do in Fiddle.

More then happy to screen share or send source code to analyse.

I'm happy (ish) as commenting out the line has fixed the issues for us as we only ever user local 'options' list so we don't loose any functionality but I thought I'd post it if anyone else has the same issue.



30 Jul 2015, 4:27 PM
Thanks for the report! This is a known issue (EXTJS-18711) which has been filed in our bug tracker.


31 Jul 2015, 1:37 AM
My pleasure, it's reassuring to know it's not something I'd broken!Do you guys have a public bug tracker I can use to track it through to resolution?CheersHerbie

31 Jul 2015, 6:16 AM
My pleasure, it's reassuring to know it's not something I'd broken!Do you guys have a public bug tracker I can use to track it through to resolution?CheersHerbie


Currently there is no public bug tracker, other than the details listed at the top of this forum post regarding the bug.