Debugging Sencha Ext JS

See how to fix rendering/layout bugs, event handling issues, data/store problems, memory leaks, slow UIs or integration issues with backend APIs. Ext JS apps are component-heavy and stateful. Knowing how to inspect components, stores and layouts is essential for reliable maintenance and performance.

High‑level process

1. Find how to reproduce the issue
2. Use framework and browser tools to locate the component/store/lifecycle point
3. Inspect component config/state and store data
4. Trace the event/data flow and network activity
5. Use profiler/heap snapshots for performance and memory issues
6. Verify fixes in production-like builds and multiple browsers

Tools you’ll use

• Browser DevTools (Chrome/Chromium, Firefox): Elements/Console/Network/Sources/Performance/Memory
• Ext-specific: Ext Inspector (browser extension or standalone component tree, configs, layouts)
• Sencha Cmd: build, dev server, generate source maps, and manage themes/build optimizations
• Logging/monitoring: console, remote logging (Sentry/LogRocket), HAR exports
• Optional: Source control, CI for automated smoke/perf tests, remote debugging tools for devices

How Ext apps are structured

• Components: Ext.Component subclasses (panels, grids, forms, windows). They have configs, items, listeners and methods
• Views: component hierarchies and layouts (VBox/HBox/Border/Fit/Card)
• Controllers / ViewControllers: event handlers and glue logic (MVC/MVVM patterns)
• ViewModel & Data Binding: bindings, formulas and session/state management
• Stores & Models: Ext.data.Store, Ext.data.Model, proxies (ajax/rest), readers/writers, paging
• Layout managers: compute sizes, perform reflows. Many layout bugs start here
• Plugins & Mixins: added behavior may inject listeners or modify lifecycle.
• ComponentQuery & global registries: Ext.getCmp, Ext.ComponentQuery.query() for locating instances

Step‑by‑step guide

1. Locate the component instance

• Use Ext Inspector to browse component tree and click components to highlight DOM and show config
• In Console: Ext.getCmp(‘componentId’) if you know id. Use Ext.ComponentQuery.query(‘componentSelector’) (e.g., ‘grid[itemId=myGrid]’) to find components. Example:

Code

Ext.ComponentQuery.query('gridpanel[itemId=myGrid]')[0]

var c

• Use component.down(), up(), ownerCt, or getRefOwner() from controllers to navigate hierarchy.

2. Inspect config, state, and runtime props

• In Console, once you have a component:
  • console.dir(cmp) or inspect(cmp) (Chrome) to explore methods and properties
  • Examine cmp.config, cmp.items, cmp.getStore(), cmp.getView(), cmp.getEl(), cmp.el.dom, cmp.rendered, cmp.isVisible()
• For grids: inspect columns (cmp.headerCt), store (cmp.getStore()), selection model, view (cmp.getView()), and bufferedRenderer plugin if used

3. Trace event handlers and listeners

• Check cmp.listeners and cmp.hasListener(eventName). Use cmp.events to inspect observable events
• Use Ext.util.Observable APIs; for classes that extend Observable, check using cmp.getListeners? and cmp.getObservableListeners (API may vary by version)
• Use DevTools “Event Listener Breakpoints” for DOM events and add conditional breakpoints in JS handlers

4. Debug store, model, and proxy flows

• Inspect store state:
  • store.getCount(), store.getTotalCount(), store.getData().items, store.getRange(0,100)
  • Check store.getProxy() — proxy.url, reader config, writer config, and extraParams
• Monitor network requests in DevTools (Network tab) to see request/response payloads, status codes and headers. Export HAR for sharing
• For paging: check start/limit params and server response shape (total property expected by reader)

5. Use breakpoints and stack traces

• Use source maps (Sencha Cmd generates them for dev builds) to set breakpoints in original source instead of minified files. Enable source maps in browser DevTools
• Insert debugger; statements in suspect code paths (controllers, listeners). Use conditional breakpoints for loops or frequent events

6. Layout and rendering debugging

• Check layout managers: call cmp.doLayout() or cmp.updateLayout() to force recompute (use carefully in production)
• Inspect element sizes via cmp.getWidth(), getHeight(), cmp.getEl().getBoundingClientRect()
• Look for configs that affect size: flex, width, height, min/max sizes, margins/padding. For container layouts (hbox/vbox), ensure child items have proper flex or explicit dimensions
• Watch for nested containers with 100% heights lacking parent height, this is a common “zero height” issue

7. Performance profiling & memory

• Use browser Performance tab to record interactions; look for long tasks, layout thrashing and paint counts
• Use Memory/Heap snapshots to find detached DOM nodes or retained component instances. Search for Ext.Component instances in heap snapshots to see growth over time
• Check for unremoved listeners (listeners referencing closures preventing GC) – Ext.util.Observable listeners should be removed in destroy handlers or use managed listeners (listeners config with scope and destroy cleanup)

8. Ext-specific debugging tips

• Ext.getVersion() gives Ext JS version this is helpful to know for API differences
• Ext.Loader and dynamic class loading: watch network requests for class files in dev mode. In production, classes are bundled by Sencha Cmd, use separate dev builds to debug class loading
• Use Ext.each, Ext.Array methods and Ext.apply/Ext.merge carefully, misuse can mutate shared configs. Prefer clone/copies when reusing config objects
• For grids with buffered rendering or infinite scrolling, inspect bufferedRenderer plugin config (view.bufferedRenderer) and server-side total/offset behavior
• Use ComponentQuery to find components even without ids, be careful with overly broad queries for performance reasons

Common pitfalls and how to avoid them

• Relying on global ids: prefer itemId and ComponentQuery in large apps to avoid id collisions
• Mutating prototype objects used as configs. Always clone config objects when reusing
• Forgetting to destroy components or remove listeners. Implement destroy handlers and use managed listeners when possible
• Using synchronous Ajax in production or blocking UI during heavy processing. Offload heavy tasks to WebWorkers or break into async chunks
• Not enabling source maps in dev. Makes stepping through original code much easier

Practical examples (Console snippets)

Find a grid and its store:

Code

var grid = Ext.ComponentQuery.query('gridpanel[itemId=myGrid]')[0];
console.log(grid.getStore().getData().items);

Get a component by id and inspect:

Code

var cmp = Ext.getCmp('myPanelId');
console.dir(cmp);

See listeners on a component:

Code

console.log(cmp.listeners || cmp.events);

Force a layout recompute:

Code

cmp.updateLayout(); cmp.ownerCt && cmp.ownerCt.updateLayout();

Sencha Cmd & builds

• Use Sencha Cmd to generate dev builds with source maps: builds created via sencha app watch or sencha app build development include easier-to-debug outputs. Production builds minify and concat files—use dev builds to reproduce and debug before producing a production build. Sencha Cmd also manages theming and classpath resolution

Logging, monitoring & sharing traces

• Use console.debug/info/warn/error with clear tags (e.g., console.debug(‘[MyApp:Grid] rowData’, rowData))
• Capture HAR from Network panel and share with teammates
• Export performance traces or heap snapshots. Anonymize any sensitive payloads before sharing
• Use remote logging (Sentry/LogRocket) for production errors, but pair with local reproductions for stateful bugs

Versioning and API differences

• Ext JS APIs and namespaces change across major versions. Always confirm Ext.getVersion() and consult corresponding docs for that version: https://docs.sencha.com/
• Some debugging techniques (internal property names, loader behavior) differ between classic and modern toolkits. Check which toolkit your app uses.

Resources and references

• Ext Inspector project/resources (search for current extension or builds compatible with your Ext version).
• Sencha Cmd docs: https://docs.sencha.com/cmd/
• Browser DevTools guides: Chrome DevTools docs, Firefox DevTools docs.