-
Notifications
You must be signed in to change notification settings - Fork 32
Migrate Ext JS 3.4 to 6.2
With Jangaroo 4 upgrading its Ext AS library from Ext JS 3.4 to 6.2, your Jangaroo code has to be adapted accordingly. As described on page Migrate Jangaroo 2 to 4, Jangaroo provides a migration tool that even covers some of Ext's API changes, but not all. Because the Ext JS version jump spans several major versions, the API changes and in some areas even semantic and conceptual changes are quite extensive.
Sencha provides comprehensive online documentation of all these changes, but they have to be collected from all the major update steps between 3.4 and 6.2:
In addition to the Upgrade Guides, for every major release, you can find "What's New" and "API Changes" documentation on the same Web site, using the navigation tree on the left hand side.
In the following sections, selected changes in the API and behavior of Ext JS 6.2 compared to version 3.4 are described that have major impact on typical Jangaroo application code or debugging. This information should help you with making your Jangaroo application work again after applying the automatic migration tools as described on page Migrate Jangaroo 2 to 4.
Memory leak debugging has become more difficult, because Ext JS will not provide a proper class name that the Chrome memory debugger can use. You should use the Ext JS patch provided in CoreMedia/ext-js/tree/ext-js-6-named-constructors@github to find specific leaks more easily.
The idea behind Ext JS's BoxLayout has always been clever. However, in Ext JS 3,
hbox and vbox layouts were very buggy. You either had to find your
way with other layouts (especially ColumnLayout for horizontally aligned
components) or you had to apply numerous manual fixes to component
widths/heights.
In Ext JS 6, both BoxLayout variants work really well. Get rid of your manual
fixes and hacks and see how smooth things go now. BoxLayouts are
superior to many other layouts when it comes to details. For example,
ColumnLayout does not handle scrollbars very well.
If the message "layout run failed"; appears in the context of box
layouts, consider adding a flex="1" config option to one of the
components. Ext JS might fail to make the box wide enough or high
enough.
Component queries are widely used to access child components in a container. To this end the following functions are used in Ext JS 3:
-
Ext.Container#find() -
Ext.Container#findByType() -
Ext.Container#findBy() -
Ext.Container#findById()
They are all gone in Ext JS 6 (breaking changes) but the first two are added as deprecated backwards-compatibility functions and the last two functions can be migrated automatically by the "Jangaroo Migrate to Ext JS 6" IDEA Plugin (see Migrate Jangaroo 2 to 4) to equivalent functions:
-
Ext.Container#findBy() --> Ext.container.Container#queryBy() -
Ext.Container#findById() --> Ext.container.Container#queryById()
For the first two functions there are no equivalent functions in Ext JS 6. Therefore Jangaroo Ext AS 6 provides two Ext JS overrides:
-
Ext.container.Container#find() -
Ext.container.Container#findByType()
They use queryBy() under the hood. Nevertheless, these two functions are
not Ext JS 6 API and deprecated.
Instead, they should be replaced by the standard Ext JS6 API (Ext.ComponentQuery - Ext JS - Sencha Docs):
-
Ext.container.Container#query() -
Ext.container.Container#down() -
Ext.container.Container#queryById()
The most common use case is searching for a child component with a given itemId.
In Ext JS 3 for example:
var uploadPanel:Container = find('itemId', 'folder-list')[0];
In Ext JS 6:
var uploadPanel:Container = queryById('folder-list') as Container;
which is equivalent to:
var uploadPanel:Container = down('#folder-list') as Container;
Note that queryById()/down() return not an array but the first matching
component.
When searching for a child which has a given value for a given property, the code in Ext JS 3 looks like:
var nameField:TextField = find('name', propertyName)[0];
In Ext JS 6:
var nameField:TextField = down('[name='+ propertyName]') as TextField;
The two Ext JS 6 functions down() and query() need as arguments
so-called selectors. Unfortunately the selectors in Ext JS 6 don't
support dots in values for xtype, id or itemId.
Unfortunately, EXML derives the xtype value from the fully-qualified name
of the config class, so it contains lots of dots.
For example, when you are searching for a component com.acme.Foo with
config class com.acme.config.foo in a container the code in Ext AS 3
looked like this:
var fields:Array = findByType(com.acme.Foo.xtype);
When replacing findByType() by query(), be sure to escape all dots first:
var fields:Array = query(com.acme.Foo.xtype.replace(/\./g, "\\."));
You should define a utility function for this task (or just keep using findByType()).
Ext JS 6 seems to behave subtly different with respect to escaping. Check whether a user-provided text can be exploited for script injection at any place where it is rendered.
Known so far: columns and column editors. Play it safe and check everything.
Sometimes, the nex Ext JS escapes more, resulting in double escapes, which are bad in their own right. Just make sure to check other uses of a value after removing a presumedly superfluous escape.
When using a DisplayField also make sure you have
the right configuration for DisplayField#htmlEncode (defaults to
false!).
It was never allowed to use the same ID for two components. However, Ext JS 6 will complain loudly while Ext JS 3.4 simply forgot about one component.
Ext JS 6 checks an itemId whether it conforms to a certain syntax
(regular expression) and complains if it does not.
It used to be possible to add a listener to a component even before the component was initialized. Now, such a call throws an error.
Form panels were configured with a default form layout in Ext JS 3.4. In Ext JS 6 they use an anchor layout by default.
The attribute Field.startValue has been renamed to Field.originalValue.
It is public API now. Unfortunately, the migration tool's map does not
yet cover this case.
In Ext JS 6, selectionModel.select([]) is simply ignored. It used to
clear the selection. Use the dedicated clearSelection() method instead.
The ordinary GridColumn no longer supports the tpl config any longer.
Use a TemplateColumn instead.
Columns used to be reusable, that is, one column could be used in multiple grids. Now columns are removed from all grids except the last to which they are added. This may cause grids to become empty unexpectedly. Take care to clone columns before using them.
When checked or unchecked, checkboxes now fire a change event, no longer
a checked event.
In a CheckboxGroup, the function getValue() now returns an object with
key value pairs where the key is the name of the checkbox and the value
indicates its checked state. The value indicating the checked state can
be specified using the attribute inputValue.
A CheckboxGroup can contain multiple checkboxes with the same checkbox
name. The value object will contain a array with the inputValues of all
checkboxes with the same name.
Combo boxes send a value event even while search terms are entered
into their text fields. Use the select event to reliably detect
changes of the combo box.
The style class for detecting selectable items in a custom combo box
template is x-boundlist-item now.
As for checkboxes, the getValue() function of comboboxGroups returns an
object with key value pairs.
Radio elements in a RadioGroup need to have a unique name in the context
of the component that they are used in. This is especially important for
a RadioGroup inside a reused component. If the Radio elements' name is
not unique, all of the application's Radio elements with that name will
get updated (see Radio.onChange(), where the Ext.form.RadioManager
collects all Radio elements by name and sets their value).
Although allowed by the API, passing the x/y coordinates as a two-element array leads to occasional wrong positioning of the context menu. Passing the coordinates as two distinct arguments for x and y is more robust.
Some events have been renamed. More events have a new signature. To just
given one example: For grids, lists and trees the contextmenu event
has been replaced by separate item and container events.
Ext.fly() must not be called from an ActionScript constructor without
providing the optional second argument. Reason: The name of the fly
defaults to the name of the calling method, which would be
constructor. However, constructor is also an implicit field of the
internal map of flies, causing an exception after the deformed fly is
extracted from the map.
When using an Ext.menu.Menu with scrollable = true without the
Ext.scroll.Scroller, then you have to explicitly remove the
overflowHandler via the layout:
<layout><VBox overflowHandler="none"/></layout>
For details, see http://docs.sencha.com/extjs/6.0.2/classic/Ext.layout.container.Box.html.