Ext JS 4 Upgrade Guide

Ext 4 is a revolutionary step forward in web app development. Almost every major component within the framework has been improved, in many cases drastically so. There are also many components and subsystems that are brand new since Ext 3. This guide will provide an introduction to all major changes between Ext 3 and 4.

If you find any issues in this document or would like to provide feedback, please visit the Ext 3 to 4 Migration thread in the Sencha forums.

General

These changes apply across both Ext Core and Ext JS.

Ext 3 Compatibility

Ext 4 is by far the most comprehensive update to Ext JS that we've ever produced, and many changes were required that are not compatible with Ext 3. However, we've gone to great lengths to provide as much backwards- compatibility as possible.

JS Compatibility Layer

This is an optional JavaScript file that can be referenced after Ext 4 is loaded that will provide the aliases and overrides necessary to make the vast majority of Ext 3 code run correctly under Ext 4 as-is.

You can download the Ext JS 3 to 4 Migration Pack from the 'Related Downloads' section of the Ext JS Download page

Sandbox Mode

Ext 4 has introduced changes that now make it possible to completely sandbox previous versions of the framework alongside Ext 4 within the same page. On the JavaScript side, this is possible with the removal of all prototypal enhancements to core JavaScript objects in Ext 4. Now you can simply alias the global Ext object to a different name and be completely isolated from previous Ext versions.

On the markup/CSS side of things, Ext 4 now uses CSS generated from templates using Compass & SASS, so it is trivial to customize the prefix of all CSS rules defined by the framework. Combined with the new Ext.baseCSSPrefix property, it is now extremely easy to isolate markup generated from multiple versions of Ext on a single page.

Package & Namespace Updates

All classes and packages have been restructured according to a strict naming convention. This makes classes more consistent and easier to find. For example, in Ext 3 classes like Button, CycleButton and SplitButton are simply grouped under /widgets (along with many other classes). The classes are also defined directly on the global Ext object.

In Ext 4, every class has been consistently placed into packages and namespaces based on related functionality. This is not entirely new, but was never consistently enforced in Ext 3. Back to the Button example above, in Ext 4 these classes are now:

• Grouped into a single src/button/ package at the file level
• Grouped into a new Ext.button namespace in code
• Renamed based on the new namspaces (e.g., Ext.SplitButton -> Ext.button.Split)

All classes that were reorganized are still available via the new alternateClassName property, so Ext 3 classnames will still work under Ext 4 if necessary (e.g. alternateClassName: 'Ext.SplitButton'). Going forward with Ext 4 development it's recommended that you migrate to the new conventions in your own code.

Ext Core

New Class System

Resources

Overview blog post & demo

Ext of course is already built on a powerful prototype-based class system, which approximates a traditional OO-based class system. In Ext 4 we've taken our class system to a new level of flexibility with the addition of many key features, and best of all the changes are 100% backwards-compatible with the Ext 3 class system. The main new features are:

• Ext.define to create class definitions within the new system
• Automatic dependency management and dynamic class loading
• Mixins
• Statics
• New config option for Automatic setter / getter generation

{@img ext4-class-system.jpg Ext 4 Class System}

Class Definition

You can still use the tried and true new ClassName() syntax in Ext 4, but the preferred syntax going forward is to use the new Ext.define function to define new classes. By defining classes explicitly within the Ext class system all of the additional class features in the following sections become enabled. The new keyword will still work, but without those benefits.

An additional benefit of using Ext.define is that it will automatically detect and create new namespaces as needed, without the need for explicitly defining the namespaces separately from declaring the classes that use them.

Here's a simple example of the old and new syntax for how you would define a custom class that extends an existing Ext component:

// Ext 3:
Ext.ns('MyApp'); // required in Ext 3
MyApp.CustomerPanel = Ext.extend(Ext.Panel, {
    // etc.
});

// Ext 4
Ext.define('MyApp.CustomerPanel', {
    extend: 'Ext.panel.Panel',
    // etc.
});

Class Loading

Ext 4 now includes a robust dynamic class loading system that also provides integrated dependency management. Again, this is an optional feature, but provides a couple of key benefits:

• Dynamic loading: Classes can be loaded dynamically and asynchronously at runtime simply based on the dependency tree that Ext manages internally. This means that you can stop managing brittle blocks of manual include tags in HTML pages and simply let the class loader figure out what your page needs to run. This is mostly useful in the development environment when dependency flexibility is more important than page load speed.

• Dynamic build generation: For production, it's usually preferable still to compile down to a single (or few) build files. Since Ext now understands the entire dependency graph at runtime, it can easily output that graph as needed (for example, in the form of a custom build configuration). And even more importantly, this capability is not restricted to the Ext namespace. You can include any number of custom classes and namespaces in addition to Ext and as long as everything is defined using the class system Ext will be able to figure out how they all relate. In the very near future, any Ext developer will have one-click custom build capability that automatically manages the entire Ext + custom application class graph, even as it changes from one minute to the next, and only builds exactly what's actually needed by the app.

This dynamic loading is enabled simply by using Ext.define and by defining the dependencies in code using two new class properties:

• requires: The class dependencies required for a class to work. These are guaranteed to be loaded prior to the current class being instantiated.
• uses: Optional class dependencies that are used by, but not required by, a class. These can be loaded asynchronously and do not have to be available for the class to be instantiated.

Mixins

This is a new approach to plugging custom functionality into existing classes. The new mixins config, included during instantiation of a class, allows you to "mix in" new capabilities to the class prototype. This is similar to the existing Ext.override function, although it does not replace existing methods like override does, it simply augments the prototype with whatever is new. Example syntax:

Ext.define('Sample.Musician', {
    extend: 'Sample.Person',

    mixins: {
        guitar: 'Sample.ability.CanPlayGuitar',
        compose: 'Sample.ability.CanComposeSongs',
        sing: 'Sample.ability.CanSing'
    }
});

Statics

Any class can now define static methods simply by defining them in its statics class property.

Config

In Ext we currently use the term config to mean any properties on a class prototype that, by convention, make up its configurable API and can be set by calling code. While this is still true in Ext 4, there is also a new optional config that's actually called config. When configuration properties are added to the config property, it will automatically generate a getter, setter, reset and apply (template method for custom setter logic) methods matching that property. For example, given this code:

Ext.define('MyClass', {
    config: {
        title: 'Default Title'
    }
});

...the following methods will get generated automatically behind the scenes:

title: 'Default Title',

getTitle: function() {
    return this.title;
},

resetTitle: function() {
    this.setTitle('Default Title');
},

setTitle: function(newTitle) {
   this.title = this.applyTitle(newTitle) || newTitle;
},

applyTitle: function(newTitle) {
    // custom code here
    // e.g. Ext.get('titleEl').update(newTitle);
}

Env Namespace

Provides access to comprehensive information about the host browser and operating system, as well as a complete list of modern browser feature detection.

Ext.env.Browser

This class provides all of the browser metadata (name, engine, version, isStrict, etc.) that used to exist directly on the global Ext object.

Ext.env.FeatureDetector

This is a brand new class whose functionality did not exist in Ext 3. It provides properties detailing the feature capabilities of the running host environment, primarily to detect the availability of modern HTML5 and CSS3 features, as well as mobile features, including:

• CSS transforms / animations / transitions
• SVG / VML
• Touch availability / Orientation
• Geolocation
• SqlDatabase
• Websockets
• History
• Audio
• Video

Ext.env.OS

Identifies the current host operating system, and includes a more comprehensive list than Ext 3 did (adding various mobile OS'es).

Lang Package

Much of the functionality within this new package existed under Ext 3, but as modifications to core JavaScript object prototypes. While this was convenient, it made it very challenging for Ext to coexist with other frameworks that modified the same objects. It also meant that Ext was directly exposed to any changes that might occur in the ECMAscript specification going forward. To remedy these problems we've completely removed all core JavaScript object modifications and placed them all into appropriately namespaced static classes under the Ext object.

All of the Prototype enhancements to the following objects have been moved accordingly (note that there is not actually a lang namespace -- it's just the package that holds these new files in the source tree):

• Array -> Ext.Array
• Date -> Ext.Date
• Function -> Ext.Function
• Number -> Ext.Number
• Object -> Ext.Object
• String -> Ext.String

Note that these will all be aliased back to the core object prototypes in the compatibility file, but in order to fully move to Ext 4 and remove the extra compatibility layer the usage of any of the Ext 3 versions of these functions will ultimately have to be updated to the new namespaced versions.

Ext.Function

There are a few noteworthy changes to how the base Function prototype methods have been implemented in Ext 4. Most importantly, the Function.createDelegate and Function.createCallback methods are now named Ext.Function.bind and Ext.Function.pass respectively. Likewise, Function.defer is now available as Ext.Function.defer. Because these three functions are so commonly used, they are also aliased directly onto the Ext object as Ext.bind, Ext.pass and Ext.defer.

The other Function methods like createSequence and createInterceptor have also been moved to Ext.Function, and there are also a few new useful additions like createBuffered and createThrottled.

Here are some examples of how the invocation syntax has changed:

// Ext 3:
myFunction.createDelegate(this, [arg1, arg2]);
myFunction.defer(1000, this);

// Ext 4:
Ext.bind(myFunction, this, [arg1, arg2];
Ext.defer(myFunction, 1000, this);

Ext JS

Resources

• Intro to Ext 4 (video)
• Ext 4 Architecture (video)

General

Adapters

In previous versions of Ext through version 3 we supported the use of third- party base libraries via adapters. As of Ext 4 this support has been discontinued. Moving forward, Ext Core will be the required foundation for all Ext JS applications. Of course third party libraries may still be optionally used in addition to Ext Core (and in fact this will even work better now that JavaScript object modifications have been removed from Ext), but they will no longer be supported as base library dependencies for Ext.

ARIA

Ext 4 features a new level of accessibility with full ARIA support baked right into every component in the framework. Ext.Component now has a config property called ariaRole which defaults to "presentation" (meaning the role is simply visual and provides no user interaction functionality) but can be easily overridden as needed. For example, Ext.button.Button overrides the default with ariaRole:'button'. This renders the standard role HTML attribute into the wrapping markup tag and tells screen readers that the contained markup (no matter how complex) functionally represents an action button. This is hugely important for accessibility and is now implemented throughout Ext.

Another important ARIA hint that is built into Ext.Component is automatic adding/removing of the standard aria-disabled HTML attribute to signify the enabled state of functional UI elements to screen readers.

Data

The data package has seen a significant upgrade since 3.x. Data is one of the many packages that Ext 4 now shares with Sencha Touch, and there is already a huge amount of information about it available today. Here are a few of the articles that give some background on the new capabilities -- we strongly suggest reading at least the first one before diving into code:

Resources

• Ext 4 Data Overview (blog post)
• Models (blog post)
• Proxies (blog post)
• Validations & Associations (blog post)

Overview

Most of the changes in the data package are non-breaking when including the Ext 3 compatibility file. The biggest updates have come to Store, Proxy and Model, which is the new name for Record:

• Store no longer cares about the format of the data (e.g. no need for JsonStore, XmlStore and other store subclasses). It now delegates all of its loading and saving to the attached Proxy, which now receives the Reader and Writer instances. Store can also perform multi sorting, filtering and grouping dynamically on the client side, and can synchronize itself with your server

• Proxy can now be attached to either a Store or directly to a Model, which makes it easy to manipulate data without a Store. Proxies can be configured with Readers and Writers which decode and encode communications with your server.

• Model is a much more capable version of Record, adding support for associations, validations and much more.

Ext JS 4 also features the brand new LocalStorageProxy which seamlessly persists your Model data into HTML5 localStorage.

Draw

This package is entirely new and has no Ext 3 analog. This is an entire library that provides custom drawing capabilities by abstracting the standard SVG and VML engines, choosing the best one available at runtime based on the current browser. This package provides the foundation for the new charting package in Ext 4, but can also easily be used for any type of custom drawing and graphics needs. Here are the major features:

• HTML5 standards based
• Rendering of primitive shapes, text, images, gradients
• Library classes for manipulating color, matrix transformations, etc.

• Ext.draw.DrawComponent

  • Extends Ext.Component
  • Engine preference via feature detection
  • Customizable engine preference order
  • Layout participation

• Built-in sprite management via Ext.draw.Sprite

  • Abstracted drawing elements
  • Normalizes differences between engine API syntax
  • Attributes
  • Event support (extends Observable)
  • Transforms (Rotate, Translate, Scale)
  • Animation supported through Ext.fx
  • SpriteComposites

Charting & Visualization

Charting in Ext 4 is a huge step forward from Ext 3, which did support charting, but only Flash-based. In Ext 4 we've completely removed Flash from the picture, yet retained complete best-of-breed browser support (all the way back to IE6) using Canvas, SVG and VML. The charting engine automatically selects the best engine for the current platform at runtime, and everything is rendered uniformly and with the best possible performance across all supported browsers. More importantly, all charting functions share a single uniform API, regardless of the underlying charting engine in use.

Resources

• SenchaCon Overview (video)
• SenchaCon Overview (slides)
• {@img working-with-charts.gif Working with Charts}

Fx

In Ext 3, the Fx class mainly provided a set of useful Element effects (slide, highlight, fade, etc.). In Ext 4 this basic functionality has been retained, but there is an entire Fx package that goes far beyond simple element effects.

There's now an underlying Animator class that coordinates multiple animations concurrently running on the page.

Components may now be animated in size and position via new Fx "target" classes (Ext.fx.target.*), which opens up many new possibilities for creating dynamic UI's.

Layout

Resources

• Ext 4 Layouts (video)
• Ext 4 Layouts (slides)

ComponentLayout

Complex components use the new ComponentLayout (as opposed to ContainerLayout, the new name for the traditional Container-based layouts carried over from Ext 3) to perform sizing of internal elements in response to resize calls. An example of this is the FieldLayout which manages the size and position of both an associated label and input element within the containing Field Component.

FormLayout

As of Ext 4, FormLayout is no longer available. See Layout in the Form section later in this document for details.

BorderLayout

Border layout in Ext 4 is fully backwards-compatible to Ext 3.

Panel Headers now may be orientated vertically, so east and west regions are replaced on collapse by a vertical header (a full-fledged Ext.panel.Header instance, unlike the simple Element in Ext 3) containing the title rotated by 90 degrees (courtesy of Ext 4's new Draw package). The placeholder Header is accessible using the layout's new getPlaceholder method. The placeholder Component is not rendered until the Panel is first collapsed. All the methods of the Ext.panel.Header class are available on it. As a Container subclass, it also inherits all the methods of Container.

Another small difference is that the cmargins config is no longer supported. The placeholder Header now has the same margins that the expanded Panel did. This makes it easier to create layouts which look good in both collapsed and expanded states by default.

Internally, the BorderLayout class now uses nested HBox and VBox layouts to create the bordered arrangement, making the layout much more flexible and customizable than it has ever been.

Component

Any Component subclass may now be configured as floatable using the floating:true config to specify that it floats above the document flow. Floating components may be configured as draggable and/or resizable using the standard configs. They may also be added as child items to any container, in which case they will not participate in the container's layout, but will float above it.

All floating Components now have their z-index managed by a ZIndexManager. This is the successor to the Ext 3 WindowGroup class. By default, floating components (such as Windows) which are rendered into the document body by having their show method called are managed by the singleton Ext.WindowManager. All floating components therefore have a toFront and toBack method which invokes the ZIndexManager.

Floating components which are added to a specific Container acquire a ZIndexManager reference at render time. They search for an ancestor Container from which to request z-index management. Usually, this will be provided by the singleton Ext.WindowManager, but if the floating component is the descendant of a floating Container such as a Window, that Window will create its own ZIndexManager instance, and all floating Components within will be managed relative to the Window's z-index.

This is a huge improvement over previous versions of Ext, in which complex arrangements of floated containers could quickly lead to z-index conflicts among different components. Now, for example, the dropdowns of combo boxes that are contained in a window will always be correctly managed above that window.

Form

Layout

In Ext 3 the FormPanel used the FormLayout class for positioning field labels, input boxes, error indicators, etc. In Ext 4 FormLayout has been removed entirely, in favor of using standard layouts for overall arrangement and the new FieldLayout (one of the new ComponentLayout classes) for the field labels etc. This makes it now possible to use any kind of standard layouts within any form, making the creation of custom form layouts exceedingly simple compared to Ext 3.

The default container layout for FormPanel is now anchor, although any standard layout may now be used within forms.

FieldContainer

Ext4 also introduces a new class for managing form layouts: Ext.form.FieldContainer. This is a standard Ext.Container which has been enhanced to allow addition of a label and/or an error message, using all the same configurations regarding label and error placement that are supported by Ext.form.Labelable. The container's children will be confined to the same space as the field input would occupy in a real Field. This makes it easy to add any group of arbitrary components to a form and have them line up exactly with the form's fields.

Field as Mixin

One longstanding difficulty with Ext has been adding non-Field components into a form with field-like capabilities like layout, validation, value management, etc. The only way to easily inherit field behavior in Ext 3 was to subclass Ext.form.Field directly, but in reality many components must subclass something outside of the Field class hiearchy. Since Ext (and JavaScript) has no support for true multiple inheritance, the result is normally copying most if Field's code directly into the custom class, which is non-optimal to say the least.

Now that Ext 4 supports mixins as part of its updated class system, this is no longer an issue. Field can now be used as a mixin to any other component, making it simple to provide full Field API support to almost anything. And of course you can easily override methods as needed if the default Field behavior needs to be customized (it is common to override getValue and setValue for example).

Validation

A common desire when building forms is to give the user feedback on the validity of fields as immediately as possible, as the user is entering data. While this could be done in Ext 3, it was clumsy and required using the monitorValid option on FormPanel which was non-optimal for performance because it invoked full-form validation several times per second.

In Ext 4 we have reworked form validation to make immediate feedback more elegant and performant. This is enabled mainly by implementing a new event flow:

• Input fields now listen to a set of modern browser events that allow us to detect changes immediately as the user makes them via any possible method, including typing, cutting/pasting, and dragging text into the field. We handle these events and roll them up together, firing the field's changeevent when a change in its value is observed (discussed further below).
• Each field validates itself when its value changes. When its validity changes from valid to invalid or vice-versa, it fires a new validitychange event.
• When any of the validitychange events fired by the fields causes the overall validity of the enclosing form to change, the BasicForm fires a validitychange event of its own.

This new event flow allows for immediate feedback to users regarding the validity of the form, and because it is based on events rather than polling, performance is excellent. Therefore, this is now the default behavior (it had to be enabled explicitly in Ext 3), though it can of course be easily disabled.

There are still situations, however, in which polling may still be useful. Some browsers (notably Opera and older versions of Safari) do not always fire events when fields are edited in certain ways such as cutting/pasting via the context menu. To handle these edge cases, you can use the new pollForChanges config on FormPanel to set up interval polling for changes to field values; this triggers the same event flow above. While polling is still not great for performance, this is less intensive than Ext 3's polling because it only checks for value changes, rather than forcing validation (and therefore value parsing, conversion, and pattern matching) each time.

The validation of each field is now triggered when a change in the field's value is detected (assuming the validateOnChange config is left enabled). The browser events used to detect value changes are defined by the checkChangeEvents config, and are set to the following by default:

• change and propertychange for Internet Explorer
• change, input, textInput, keyup, and dragdrop for all other browsers

This set of events successfully detects nearly all user-initiated changes across the set of supported browsers. The only known exceptions at the time of writing are:

• Safari 3.2 and older: cut/paste in textareas via the context menu, and dragging text into textareas
• Opera 10 and 11: dragging text into text fields and textareas, and cut via the context menu in text fields and textareas
• Opera 9: Same as Opera 10 and 11, plus paste from context menu in text fields and textareas

If you must absolutely ensure that changes triggered by the above actions also trigger validation, you can use FormPanel's pollForChanges and pollInterval configs, and/or startPolling and stopPolling methods to check for changes on a timer.

Ext 3 supported the formBind property on buttons added to the form via the buttons property, which allows them to be automatically enabled/disabled as the form's validity changes. In Ext 4, this has been expanded so that formBind may be specified on any component that is added anywhere in the FormPanel.

FieldDefaults

One time-saving feature of the old Ext 3 FormLayout was that it allowed developers to configure the layout of all fields within the form from a single config, using the hideLabels, labelAlign, etc. config properties of FormPanel. Since Ext 4 now uses the standard layouts for form containers, it would be much less convenient to have to specify common field layout properties again and again for each field or container. Therefore FormPanel now has a fieldDefaults config object, which specifies values that will be used as default configs for all fields at any depth within the FormPanel.

BasicForm

While BasicForm was most often limited to internal use by FormPanel in Ext 3, it has been refactored in Ext 4 to make it more flexible and more easily extended. It no longer requires its associated container to provide a <form> element around all the fields, and does not require its container to manually notify the BasicForm when adding or removing fields. It is therefore now completely decoupled from FormPanel, and can potentially be used to manage form fields within any Container.

Grid

The grid components have been rewritten from the ground up for Ext 4. While this was for good reason and the benefits will be well worth it, unfortunately this is one of the areas in Ext 4 where full backwards compatibility could not be practically maintained. A complete migration guide will be provided to assist with the transition from Ext 3 to 4 grids.

Intelligent Rendering

Ext 3's grid works fantastically well, but takes the "least common denominator" approach to its rich feature support by always generating the full markup needed by every grid feature (which is overly-heavy in most cases). Ext 4 takes a much more intelligent approach to this problem. The default basic grid has very lightweight markup, and only as developers enable different features will the additional feature-specific markup be rendered. This is a huge boost both for page rendering speed and overall grid performance.

Standardized Layout

Along with a smarter rendering pipeline, many portions of the new grid have been made into proper Components and integrated into the standard layout management system rather than relying on custom internal markup and CSS. This enables us to unify grid's rendering process with the rest of the framework, while still retaining a pixel-perfect UI experience.

One useful example of this is the new HeaderContainer class. In Ext 3 column headers were baked into the grid and not very customizable. In Ext 4 the column headers are true Containers and now use a standard HBox layout, allowing you to do things like provide custom flex values per column.

Feature Support

In Ext 3, it was easy to add new functionality to grids, but there was no single strategy for doing so. Many added features were provided as plugins, but then some were provided via subclassing. This made it very difficult (if not impossible) to combine certain features easily.

Ext 4 includes a new grid base class called Ext.grid.Feature which provides the basis for creating extremely flexible optional grid features. The underlying templates can now be modified by any Feature classes in order to decorate or mutate the markup that the GridView generates. Features provide a powerful alternative to subclassing the old GridView because it makes it easy to mix and match compatible features.

Some examples of the features now available in the Ext 4 grid are:

• RowWrap
• RowBody
• Grouping
• Chunking/Buffering

Virtual Scrolling

The Ext 4 grid now natively supports buffering its data during rendering, providing a virtual, load-on-demand view of its data. Grids will now easily support hundreds or even thousands of records without paging, which will be a massive improvement over Ext 3's grid capabilities.

Editing Improvements

In Ext 3 you had to use the specialized EditorGrid class to provide an editable grid, which limited its flexibility. In Ext 4 there is now an Editing plugin that can be applied to any grid instance, making it completely reusable across all grids.

As part of the editing improvements, the popular RowEditor extension from Ext 3 has been promoted to a first-class and fully-supported framework component in Ext 4.

DataView

The new GridView in Ext 4 extends the standard DataView class now. This not only minimizes duplicated code internally, it also makes the new grid even easier to customize. Because it extends DataView the new grid is also able to leverage the same selection models as any view, including discontinguous selection via keyboard navigation. The Home, End, PageDown and PageUp keys are also fully supported.

Panel

Docking Support

Panel now uses a panel-specific ComponentLayout class to manage a set of items docked to its borders. The Panel's body element is then sized to occupy any remaining space. Any components may be docked to any side of a panel via the new dockedItems config property, and docked items must be configured with a dock property to specify which border to dock to. This allows for amazingly flexible Panel layouts now -- things that were impossible in Ext 3 like vertically-docked side toolbars are now a breeze to implement in Ext 4.

Header Improvements

Header is now a first-class Container subclass, inheriting capabilities like child component management and layout. Headers may also be configured with a headerPosition of 'top', 'right', 'bottom' or 'left' via the new docking support.

Tools (the small header buttons that perform actions like minimize, close, etc.) are also now proper Components making them even more flexible than they were in Ext 3.

Resizer

Ext has had handle-based resizing built-in since the earliest days of the framework, but through Ext 3 it was limited to resizing DOM elements only. Now in Ext 4 any Component can be resized via the new Ext.resizer.Resizer and its associated components. This is mainly useful when applied to floating components, or components programmatically rendered outside of Ext's Container system.

By configuring a component with resizable:true, resize handles are automatically added to the Component's edges. By default a proxy element is resized using the mouse, and the Component is resized on mouse up. Behavior of the resizer can be modified by specifying the resizable property as a config object for the Resizer class.

ComponentDragger

Ext has always had extensive drag-and-drop support, but primarily at the DOM element level. In Ext 4, any Component can now easily be made draggable as well via the new Ext.util.ComponentDragger class. This is mainly useful for floating components, or components programmatically rendered outside of Ext's Container system.

By configuring a component with draggable:true, it automatically becomes draggable with the mouse. Panels that are made draggable by this method (Windows configure themselves as draggable by default) show an empty ghost during the drag operation and the Panel or Window is shown in the new position on mouse up. Behavior of the dragger can be modified by specifying the draggable property as a config object for the ComponentDragger class.

Splitter

Both the HBox and VBox layouts may contain Ext.resizer.Splitter components which are used to manage the size of their adjacent siblings. Minimum and maximum size settings are supported. By default, resizing a flexed item of a box layout sets its size in pixels and deletes the flex value. One of the splitter's two adjacent siblings may be configured with maintainFlex:true to preserve its flex value after the resize operation.

TabPanel

As with many other components in Ext 4, the main pieces that make up a TabPanel have now been made into first-class Components in Ext 4. The Tab itself, just a DOM element in Ext 3, is now a Button subclass. The TabBar that contains the tabs is now a Container. These changes provide much more flexibility over Ext 3.

Because tabs are now separate components from the contained child panels that hold the tab content, individual tab panels can now optionally show their own title header bars separately from their tab titles. This was impossible in Ext 3.

Toolbar

Toolbar is now a first-class Container, which will make adding new components and customizing its layout much easier than in Ext 3.

Theming

The theming in Ext has always been amazing, but not as easy to customize as it could be. Ext 3 made strides in this area by separating structural and visual stylesheets, but there is still quite a bit of duplication, browser-specific override rules, and many other issues that are simply weaknesses of the CSS language itself.

Resources

• Ext 4 Theming (video)
• Ext 4 Theming (slides)

Compass & SASS

For Ext 4 we've completely retooled the theming system, switching to Compass and SASS as the primary CSS authoring tools internally. SASS is a superset of standard CSS that adds support for many advanced features:

• Nested selectors
• Variables
• Mixins
• Selector inheritance
• Compiled and easily compressed
• Ability to completely remove CSS for components not needed by your specific application

Markup Changes

Ext now supports browser/version-specific markup for most components, which is a great advance from Ext 3.

Documentation

• Support for new class system constructs (requires, mixins, etc.)
• Support for @deprected members
• History navigation support
• Embedded examples, videos, etc.
• Favorite topics
• Multiple framework / version support
• Local search