What Will extjs 4.1 bring?

Original article: http://www.sencha.com/blog/whats-new-in-ext-js-4-1/

The focus of extjs 4.1 is performance. We have been working hard for this, and this is mainly focused on two aspects:RenderingAndLayout. Although ourMajorityTimeAlwaysCommitmentThisItem effort, But there are alsoManyThe progress of other methods is acceptable.Share. The main improvements include grid, borderlayout, and Neptune topic preview.

Performance

To improve performance, you must measure it. Therefore,YesSuccessfullyAndPermanentLocationImprovePerformance,MeasurementAlreadyBecomeRegularBuild and test processOfPart.This is the first thing we need to do for extjs 4.1. For example, to achieve dynamic tracking in common configurations, we have created a simple test tool that is used continuously. We use these toolsTrackingEach buildOfKey indicators.

We track Corresponding Page Lifecycle Performance indicators : Load, Initialization, Rendering And Layout .

Load

The lifecycle of an extjs application starts when the "onready" function is called. Before that, many things happened. When we say "page loading", it may mean a lot of different things, but for simplicity, here we define it as the first line in the execution of the "ext-all.js"CodeStart, any onready function is called before the end time. This mainly includes executing the Ext. Define statement to fill the ext namespace and checking the time when the page Dom is ready.
Initialization

When the onready function is called, the applicationProgramStart to take over. The application starts to process custom initialization as needed, and its main task is to create components and containers to be displayed. In some applications, hundreds of components are created. Some of these components or containers are created, initialized, and connected together.

In extjs 4, components often need to be compared with previous versions. For example, the title bar of the panel is composed. The header component is actually a container that contains a basic title component and a set of tool components (optional), which are managed using hboxlayout. This means that you can easily add components to the panel title bar, or create more components and containers in extjs 4 with the same panel configuration. Looking at the theme example of extjs 3, there are 148 components in 50 containers. In extjs 4, the same configuration generates 271 components in 97 containers. This makes optimization in this aspect crucial.

(Note: One of the main reasons for the slow performance of extjs 4 compared with extjs 3 is that extjs 4 is componentized by many small container components, which increases its flexibility and ease of use, however, performance may be compromised. The most typical example is the use of panel docklayout. If you are interested, you can study it here)

Rendering

The next step is to convert these initialization components and containers into HTML. In previous versions of extjs, rendering uses a mix of calling the createelement method and setting innerhtml. In extjs 4, the main element of each component is created using createelement, and the internal structure is generated by an xtemplate instance named "rendertpl.

If a component is generated by a container, such as a panel, additional elements are created using the createelement method, and its child components are repeatedly rendered to the main element of the Panel during rendering. In each step, special methods of components are called and special events are triggered, so that the derived classes or applications can be extended.

In extjs 4.1, the rendering of components is optimized and rendering is performed in batches. Batch rendering no longer repeatedly calls the createelement method and innerhtml, but generates the HTML of the entire component tree, and then adds it to the DOM using innerhtml at one time.

To implement this change, a new method named "beforereader" is added for the component. Although beforerender events always exist, if a derived class needs to perform some operations before the primary element is created, it usually has to select between the rewrite render or onrender methods. They do what they need to do, then call the basic version method, and then create elements.

Figure 1 shows the rendering process of 4.0 and 4.1. Both processes start with a specific component and its internal component tree.

Layout

Once the DOM already contains all the necessary elements, the final step is to process the size and position of the special elements. That is to say, the final step is to layout the components. This process is complex and time-consuming. In the theme example 4.0.7, it accounts for more than half of the total loading time. The challenge of layout mainly comes from the way the browser processes styles (such as margin, width, and height), especially these methods are changing along the way.

The first rule of performance is that CSS computing is expensive. Because of this, the browser will cache these results. When JavaScript sets the width or height, it will invalidate some or all of the browser's cache. The number of caches affected by a function depends on the CSS engine of the browser and its intelligence. The next request of style information usually triggers a reflow process to refresh the cache. Generally, "read/write = reflow ". Given the high cost of reflow, a method that significantly improves performance is to reduce the Reflow Process of layout.

In extjs 4.0, an hboxlayout example caches all computation results and writes the results only after it reads the information of each component that it needs to know. If hboxlayout requires the component size, it must measure the component element (read). However, before doing so, the component layout must first complete its work. That is to say, the component layout performs some calculations (read) and then saves the results to the DOM (write ). Then, hboxlayout measures the component element (read ).

These begin with read queues, followed by write queue operations, which are often highly staggered to read and write together, resulting in a large number of reflow processes. In order to eliminate the Reflow Process of these sub-la S, the external Dom should be used to report the results to their owners.

The layout has been reconstructed in extjs 4.1, and these results are shared by the layout context object to avoid Dom read/write (and related reflow processes ). This change will be felt when a large number of internal custom la s are used. We believe this is a rare practice in an updated version.

From 4.0.7 to 4.1.0 PR1

All these optimizations have produced significant benefits. One of the key examples for extjs basic performance testing. Figure 2 shows the performance difference between 4.1 PR1 and 4.0.7 in this example on IE8.

Next step

Obviously, 4.1 is a major improvement of 4.0, but its speed has not exceeded 3.4. This is not the final factor for performance optimization. In fact, there are many other performance optimization plans in 4.X, but they are not suitable for this version. Now our goal is to quickly release a stable extjs 4.1 release. We will work hard to provide additional benefits in subsequent versions.

Other aspects

As a commitment, this version is not simply related to performance. The Neptune topic presented at senchacon this year. Its preview version will be part of this version. More happily, the calendar example will return.

The following list contains many other improvements, but we would like to dive into some more exciting changes.

Grid

Check whether there are other solutions to solve the cache scroll bar and infinite scrolling mechanism in extjs 4.0. I'm glad that we can actually solve this technical problem without using virtual scrolling.

In extjs 4.1, several grids use the native scroll bars. This greatly improves the user experience, because the grid's acceleration, rolling volume, and friction volume are the same as other rolling content. Another gratifying improvement is that the rolling effect is based on pixels rather than the whole row. This makes the infinite grid more real, even if the row height is different.

The exception is that you need to use a virtual scroll bar to lock half of the grid, because it does not have a scroll bar, and the Native scroll bar is not optional here.

Finally, although not a part of the grid itself, you can use store to process metadata (metadata ).

Borderlayout

During the layout process, the border layout has made special improvements in some internal structural adjustments. It has been a very popular layout for a long time, but it has also been subject to some restrictions for a long time:

• Only one region, such as North, South, East, or east, is allowed. If you need multiple south regions, You need to nest the boundary layout within them.
• East or west areas cannot be configured preferentially in North or South areas. To do this, you need to use nested boundary layout.
• After creation, you cannot add components to the container.
• After the component is created, it cannot be removed from the container.

We are happy to say that these restrictions have been deleted in extjs 4.1.

(This improvement is too powerful)

Xtemplate

Extjs often uses the xtemplate class internally. This is an extremely important part of the framework, but it lacks some important features: it cannot effectively add operations in the sub-process of arrays. When we started batch rendering, we decided that domhelper and xtemplate should collaborate to process tag production and push its output to a shared array.

Then we found that xtemplate could support this work without a surgical modification. This allows us to rethink the work needs. Xtemplate will be a long-term challenge and problem.

• ItOnly supportedThe most basicControl Structure:"For"And"If".
• The code generated from the template is between difficult and cannot be debugged. Therefore, it is difficult to trace errors in the template text.
• The template text is compiled during the template build time, which is not advisable because many template instances have never been used.
• The template compilation code is not as fast as you think, because it contains many internal function calls and String concatenation.

Now in extjs 4.1, xtemplate will compile it when you first use them. This is almost a free xtemplate build. In addition, the compiled code can be debugged in one step using the debugger and looks more like the original template.

This method makes it easy to support many things, such as the "else", "else if", or "Switch" statements. Even inserting code (like JSP or ASP) in the text is now a very simple extension.

VaR TPL = new Ext. xtemplate (<br/> '<TPL for = "orders">', <br/> 'order {ID} is ', <br/> '<TPL if = "Total> 100">', <br/> 'large ', <br/> '<TPL elseif = "Total> 25">', <br/> 'medium ', <br/> '<TPL elseif = "Total> 0">', <br/> 'small', <br/> '<TPL else> ', <br/> '{% continue; %}', <br/> '</TPL>', <br/> 'items: ', <br/>... <Br/> '</TPL> ');
The "<TPL for>" statement will generate a "for" loop, "<TPL if>", "<TPL elseif>", and "<TPL else>" obviously generate appropriate "if" and "else" blocks.

The new "{% x}" syntax is similar to "{[x]}". This subject is considered as any code. In the "{[x]}" expression, X is an expression that generates a value in the output. "{% X}" and "X" simply indicate inserting a function. In the current example, the loop continues when it is run.

Overrides

In extjs, we have been using the "Rewrite" Method for bug fixing and improvement for a long time. In the past, these special entities must be managed manually. To maintain existing classes, almost all other code uses the class name as a string in extjs 4.0. For example, derived from Ext. Panel. Panel:

Ext. define ('My. app. panel ', {<br/> extend: 'ext. panel. panel ', </P> <p> method: function () {<br/> This. callparent (); <br/>}< br/> });
However, if an application is rewritten in the same panel class (in extjs 4.0), the writing method is completely different:

Ext. panel. panel. override ({<br/> method: function () {<br/> This. calloverridden (); // not possible before 4.x< br/>}< br/> });
If the Panel class has not been loaded, this code will fail to be executed. The inherited use examples do not fail, but inform you of the need to load/create Ext. Panel. Panel.

Rewriting is now a first-class citizen. They can be named and loaded as needed. In fact, writing a rewrite is the same as writing a derived class.

Ext. define ('My. app. panelpatch ', {<br/> override: 'ext. panel. panel ', </P> <p> method: function () {<br/> This. callparent (); <br/>}< br/> });
This not only supports the creation and writing of traditional hosting methods, but also can become a design tool similar to Mixin. The Mixin class is always a part of the class (similar to the base class). Rewrite can be fixed as expected or as needed later.

Summary

We hope that you will have the opportunity to download and try new functions and improve the extjs 4.1 final version. We also hope to receive your feedback on this version and further improvements.

Author:Don Griffin
Don Griffin is a member of the ext JS core team. he was an ext JS user for 2 years before joining sencha and has over 20 years of software engineering experience on a broad range of platforms. his experience designing web application front-ends and back-ends, native GUI applications, network protocols and device drivers. don's passion is to build world class products that people love to use.