JS Days 2025 is now live – Join 5,000+ devs for the premier virtual JavaScript event. Register Now

Top Support Tips

October 9, 2014 2259 Views
Show

Removing Grid Cell Focus

by Greg Barry

As of Ext JS 5.0.1, we’ve added some significant improvements regarding Accessibility and ARIA support. While we do encourage users to use these new additions, we understand that the default style may not be ideal in all circumstances. In fact, there may be situations in which the focused cell border is not desired at all.

If you would like to make adjustments to the focus style, it’s best to change these properties by modifying your SASS variables and recompiling your styles.

You can find the cell focus SASS variables on the Grid View. They currently include:

While we recommend compiling style changes via the above SASS variables, you can also use the following CSS selector to modify or hide grid cell borders:

.x-grid-item-focused .x-grid-cell-inner:before {
        border: 0;
}

You can see an example of the CSS being overridden in this Fiddle.

For more information about Accessibility changes, please check out the new Accessibility Guide.


Creating Instances on the Prototype is Bad

by Mitchell Simoens

When defining a new class using Ext.define, you should never use Ext.create to create an instance on the prototype like this:
Ext.define(‘MyApp.view.Main’, {
extend : ‘Ext.container.Container’,
xtype : ‘myapp-main’,

requires : [
‘MyApp.plugins.Foo’
],

items : [
Ext.create(‘Ext.Component’, {
html : ‘Hello’
})
],

plugins : [
Ext.create(‘MyApp.plugins.Foo’)
] });

Instead, you should use configuration objects with a class alias:
Ext.define(‘MyApp.view.Main’, {
extend : ‘Ext.container.Container’,
xtype : ‘myapp-main’,

requires : [
‘MyApp.plugins.Foo
],

items : [
{
xtype : ‘component’,
html : ‘Hello’
}
],

plugins : [
{
ptype : ‘myapp-foo’
}
] });

The reason to use config objects is that when the class, MyApp.view.Main in this case, is instantiated, it will create new instances based on the config objects for you. If instances were present on the prototype, like in the first code snippet, the first instance of MyApp.view.Main would likely work just fine but any subsequent instances created would not work as expected and possibly throw errors.

In this Fiddle, you can see an example of why creating instances on the prototype is bad.

Recommended Articles

Guide to Estimating ROI When Switching From DIY Libraries to Full Software Development Platforms Like Ext JS

Teams started with Do It Yourself, or DIY, JavaScript tools like jQuery and Bootstrap. But those fall apart as projects scale. Scattered code, user interface…

Top Frameworks Developers Are Using for Custom Software Development in 2025

We’re seeing it more every year; teams aren’t settling for plug-and-play tools anymore. In healthcare, finance, logistics, and other data-heavy industries, there’s a clear shift.…

Meet Sencha AI Coding Companion: Your AI-Powered Assistant for Faster Ext JS Development

Building modern web applications should be exciting. But too often, developers find themselves buried in documentation, endlessly Googling framework quirks, or stuck solving the same…

Ext JS 7.9 & Rapid Ext JS V1.1 Have Arrived

The Sencha team is excited to announce the latest Ext JS version 7.9 and Rapid Ext JS 1.1 release – designed to accelerate development, enhance…

Top 10 JS Grid Customization Tips for a Better UI Experience

Grids are pretty much everywhere in web apps. Working with financial sheets, product details, or users? Then you’ve probably used a JavaScript grid. It makes…

Why Ext JS Framework is the Go-To Framework for Building Scalable and Data-Intensive Web Apps

Web apps are much more advanced now. They deal with large amounts of data and need to stay fast, even with many users. If you’re…

View More

Trusted by Top Developers: Learn how to enhance your development journey — for free

Get the latest newsletter keeping thousands of developers in the loop.

Loved by developers at