What’s New in Ext JS 5.0.1

Today, we are excited to announce the general availability of Ext JS 5.0.1! This maintenance release includes a number of improvements based on feedback from the Sencha community.

Lets take a tour of the changes.

Accessibility

With Ext JS 4.2.2, we released the “ext-aria” package to provide improved support for accessibility (as described in the WAI-ARIA 1.0 standard). While this was an important step to providing tools for you to make your applications accessible, we also learned a lot from the feedback we received both from our testing partners and early adopters.

With Ext JS 5, we wanted to incorporate that feedback and provide a better solution. I am delighted to say that with Ext JS 5.0.1, support for accessibility is much improved. In large part, this is because our support for focus and keyboard navigation has moved from “ext-aria” to the framework itself.

Focus

In Ext JS 5.0.1, we have greatly improved the internal handling of focus to better align with accessibility standards. The core components (such as buttons, tabs, form fields and grids) now all provide a clear, visual indication of focus. This is a key requirement for accessible applications. To give you control over these new visual aspects, we have added several new Sass variables and mixin parameters.

Keyboard Navigation

Previous releases of Ext JS provided the Ext.FocusManager to assist in managing focus. While this class remains, it is no longer the recommended approach. Instead, all components now have a “focusable” property that is used to manage the tabIndex DOM attribute. Any component with this property that is set to true will be able to receive focus either by clicking or via the keyboard.

When these focusable components are placed in certain containers (such as toolbars), the container provides arrow key navigation and manages which item will receive the focus on entry to the container.

There is lots of information about these accessibility, focus and keyboard navigation improvements. For more details, see the Accessibility Guide

ViewModels

It has been great seeing how quickly developers have picked up ViewModels and data binding. In addition to general bug fixing, there are some noteworthy improvements related to binding.

Selection Binding

Many developers have requested that we expand on the ability to use “selection” as a bindable property on those components that support the notion (such as ComboBox, Grids, Trees, Breadcrumbs, etc).

You can now use binding to keep the selections of these components in sync. For details, see the Kitchen Sink example.

Model & Field Validation

One key improvement with form fields is that two-way bindings now check that the value is valid before updating their bound properties. To support this when binding to Model fields, the form fields can now acquire the Model’s validators and include them in their own validation.

In Ext JS 5.0.0, these validators could only be consulted by first putting back the (potentially invalid) value. With Ext JS 5.0.1, you can be assured that invalid values will never be put back into your records.

Data

Ext.data also has some important fixes and improvements with this release.

TreeStore vs Node Events

With Ext JS 5.0.0, the TreeStore class was refactored to extend Ext.data.Store. In this process, however, one key problem existed: the way a TreeStore would relay events from the root node (Ext.data.NodeInterface).

For most events fired by tree nodes, everything worked as before. Unfortunately, certain node events collided with store events which created problems for listeners. One such example is the “remove” event.

The only safe and sure fix for this issue was to prefix all node events with “node” before firing them as TreeStore events. This means that the node’s “remove” event is now fired from the TreeStore as “noderemove”. While we always strive to avoid such changes in a maintenance release, there was really no way to resolve the issue without breaking either node listeners or store listeners. We apologize for the inconvenience this change may cause.

Associations

One limitation with associations in Ext JS 5.0.0 was that if you created a new record and then dropped that record, there was no cleanup logic to handle its potential child records. This could create a situation where a session would generate, create or update operations for these child records. These operations could not be processed by the server because the parent record was not saved.

With Ext JS 5.0.1, reference fields that declare parent/child ownership between Models are consulted when dropping records. When you indicate this type of association, dropped records will automatically handle deleting their child records.

For example:

Ext.define('App.model.Order', {
    extend: 'Ext.data.Model',
    // ...
});
    
Ext.define('App.model.OrderItem', {
    extend: 'Ext.data.Model',
    
    fields: [{
        name: 'orderId',
    
        // Indicates that the referenced Model (Order) owns these
        // records:
        reference: { parent: 'Order' }
    }]
});

In this way, when an Order is dropped (marked for deletion), its child OrderItems will likewise be dropped:

order.drop();

In this way, when an Order is dropped (marked for deletion), its child OrderItems will likewise be dropped:

Further, setting parent references to null (for example, by removing it from the parent’s association store) schedules that record for cleanup.

order.orderItems().removeAt(0); // removed orderItem is dropped
order.orderItems().getAt(0).setOrder(null); // also drops this item

The server is still ultimately responsible for a full cascade delete, but the above handling ensures that the client will never reference dropped records in save operations.

Responsive Configs

The new responsiveConfig provided by Ext.mixin.Responsive and Ext.plugin.Responsive provides lots of flexibility for managing dynamic conditions cleanly.

The new responsiveFormulas allows you to add properties for responsiveConfig rules to use. For example, your main controller could do something like this to publish new properties:

Ext.define('MyApp.view.main.Main', {
    extend: 'Ext.container.Container',

    mixins: [
        'Ext.mixin.Responsive'
    ],

    responsiveFormulas: {
        small: 'width < 600', medium: 'width >= 600 && width < 800', large: 'width >= 800',

        tuesday: function (context) {
            return (new Date()).getDay() === 2;
        }
    }
});

In the above example, these new values (“small”, etc.) can be used in any of your responsiveConfigs. This can really help streamline your application’s responsiveConfigs as well as give you a single place to maintain these kinds of choices.

Charts

The “sencha-charts” package also contains several improvements, such as reusable markers like arrows, diamonds, etc. For starters, there is now a build of the sencha-charts package included in Ext JS 5.0.1 for those not using Sencha Cmd. The most significant change is that we’ve documented and exposed how to create custom chart themes.

Chart Themes

In Ext JS 5.0.0, charts shipped with several built-in themes that you could select for your charts, but building custom themes was not a documented process. With this release, we have provided this ability, so you can make your own color palettes and much more.

A theme for charts is a class derived from Ext.chart.theme.Base and given an alias that starts with “chart.theme.”. A basic theme could be as simple as this:

Ext.define('App.chart.theme.Awesome', {
    extend: 'Ext.chart.theme.Base',

    singleton: true,
    alias: 'chart.theme.awesome',

    config: {
        baseColor: '#4d7fe6'
    }
});

From here, you can add any number of other configs to style your series, axes and markers. To see all the options, check out the API reference for the available configs. To use the new theme we’ve created, we simply set the “theme” config on the desired charts:

theme: 'awesome'

Sencha Cmd

Last but not least, with Sencha Cmd 5.0.1 we have expanded the options in app.json to give you much more, fine-grained control to configure things to suit your needs without having to delve into the build scripts.

output

To give you a peek at the most useful of these new controls, let’s look at the “output” object. A common requirement for some environments is to maintain the “markup” file in a folder other than where the Sencha application resides. For example:

foo.php
foo/
app.json
app.js

The difference with this model is that the markup file (“foo.php” above, but it could be anything) is in a parent folder. In previous releases, this required setting several build properties. In Sencha Cmd 5.0.1, we can now do this in app.json:

{
    ...
    "indexHtmlPath": "../foo.php",
    "output": {
        "page": {
            "path": "../foo.php",
            "enable": false
        }
    }
}

The above ensures that all paths will be calculated relative to the parent folder while also disabling the build step that rewrites the markup file. The “output” object can control many other aspects of your build’s output, from enabling compiler optimizations to tuning the microloader.

packager

Cordova and PhoneGap are now much more flexible and easier to use with the new “packager” property. This new setting allows your build to specify its packager (either “cordova” or “phonegap”) directly in app.json. Combined with the “builds” object (added in Sencha Cmd 5.0.0), we can make an app that builds for the web, iOS and Android.

For example:

{
    ...
    "builds": {
        "web": {
            "default": true // picked by "sencha app build"
        },
        "ios": {
            "packager": "phonegap",
            "phonegap": {
                "config": {
                    "platform": "ios",
                    "remote": true // use PhoneGap Build
                }
            }
        },
        "android": {
            "packager": "phonegap",
            "phonegap": {
                "config": {
                    "platform": "android" // use Local Phonegap
                }
            }
        }
    }
}

As before, we can run a build like so:

sencha app build

The above will use the “web” build definition. But now we can also do these builds:

sencha app build ios
sencha app build android

Of course, you will need to have PhoneGap installed, and you will also need to configure your PhoneGap Build credentials. Alternatively, you could remove the above “remote” config and switch to the “cordova” packager (if you have Cordova and an iOS development environment installed).

Other than formalities, you can probably see how this property cleans up your build process. Using this approach also frees you up to add “testing” to any of these builds and get uncompressed JavaScript code for debugging (something that required manual tweaks in previous releases).

Conclusion

Ext JS 5.0.1 and Sencha Cmd 5.0.1 deliver many of the most important improvements that you’ve requested. On top of all the new capabilities in Ext JS 5, we are excited to see what amazing things you can do in your apps. Download it and try it out. Then, let us know in the forums what you think.

Check Out Here Ext JS Latest Release