10 Common Errors During ExtJS Application Development

This is 10 important points that CNX has summarized in its ExtJS project development. Sometimes we use ExtJS to build new applications from scratch, but sometimes our customers will ask us to use their own code and help them improve... syntaxHighlighter. all (); this is 10 points that require special attention in the development of ExtJS projects by CNX. Sometimes we use ExtJS to build new applications from scratch, but sometimes our customers will ask us to use their own code, it also helps them improve performance, solve bugs and structural problems. At the same time, we have been working as a "cleaner" role in the ExtJS project for a long time, and began to notice that some code worth optimization often appears in the project, these situations may not only appear in our projects, but also often appear in the code of other developers. Based on the summary of our work over the past few years, we would like to share these experiences with you to avoid similar problems in the project. Excessive or unnecessary nested component structure development often causes no reason to use nested components. This will damage the performance of the software and cause poor-looking interfaces like two boundaries or abnormal layers. In the following example 1A, we have a panel that contains a simple table. In this case, this Panel is unnecessary. In Example 1B, removing this extra panel still works well. Remember these formats: trees, tab panels, and grids all inherit from the Panel. No nested Panel needs to be added when these components are used. Items: [{xtype: 'panel ', title: 'My Cool grid', layout: 'fit', items: [{xtype: 'grid', store: 'mystore ', columns: [{...}] example 1A. bad: This 'panel 'is unnecessary. Layout: 'fit ', items: [{xtype: 'grid', title: 'My Cool grid', store: 'mystore', columns: [{...}] example 1B. good: This grid is already a panel, so you can directly set the attribute in the panel. Many developers have encountered this problem because of Memory leakage caused by failed cleaning of component objects. Why is the usage of the applications they write getting slower and slower? This is probably because you fail to clear component objects that are no longer in use and that are irrelevant (user navigation. As shown in example 2A, each time you right-click a row in the table, a new context menu is created. If you keep running this application and right-click it many times, there will be a lot of objects that are not destroyed and will never be destroyed. For developers and users, because only the last menu is displayed, this application "looks" okay. In fact, it is only because the other menu objects created are temporarily hidden. Because the old menu objects are not released before the new menu is created, the memory used by the application will continue to grow. In this way, the response slows down or the browser crashes. The example 2B is more reasonable, because the menu is only created once during table initialization, and the user uses the same menu object for each right-click operation. However, if the table object is destroyed, that is, the menu object will not be used in the future, but it is still not destroyed and will always occupy the memory. The best solution is the example 2C, because the menu object will be destroyed as the table object is destroyed. Ext. define ('myapp. view. myGrid ', {extend: 'ext. grid. panel ', columns: [{...}], store: 'mystore', initComponent: function () {this. callParent (arguments); this. on ({scope: this, itemcontextmenu: this. onItemContextMenu});}, onItemContextMenu: function (view, rec, item, index, event) {event. stopEvent (); Ext. create ('ext. menu. menu ', {items: [{text: 'Do Something'}]}). showAt (event. getXY () ;}}); example 2A. difference: each right-click operation creates a menu, and each menu is not destroyed. ext. define ('myapp. view. myGrid ', {extend: 'ext. grid. panel ', store: 'mystore', columns: [{...}], initComponent: function () {this. menu = this. buildMenu (); this. callParent (arguments); this. on ({scope: this, itemcontextmenu: this. onItemContextMenu}) ;}, buildMenu: function () {return Ext. create ('ext. menu. menu ', {items: [{text: 'Do Something'}]}) ;}, onIte MContextMenu: function (view, rec, item, index, event) {event. stopEvent (); this. menu. showAt (event. getXY () ;}}); example 2B. better: The menu will only be created once during table initialization and the same menu object will be used each time. ext. define ('myapp. view. myGrid ', {extend: 'ext. grid. panel ', store: 'mystore', columns: [{...}], initComponent: function () {this. menu = this. buildMenu (); this. callParent (arguments); this. on ({scope: this, itemcontextmenu: this. onItemContextMe Nu}) ;}, buildMenu: function () {return Ext. create ('ext. menu. menu ', {items: [{text: 'Do Something'}]}) ;}, onDestroy: function () {this. menu. destroy (); this. callParent (arguments) ;}, onItemContextMenu: function (view, rec, item, index, event) {event. stopEvent (); this. menu. showAt (event. getXY () ;}}); example 2C. best: when the table is destroyed, the menu will also be destroyed. huge controller code every time we see a huge controller that contains thousands of lines of code, we will be very surprised. We tend to interrupt this huge controller by dividing it into small functions. For example, an order processing program may contain independent logical control blocks such as assembly line items, loads, and user search. By splitting it into small processing functions, you can make it easier and easier to search and manage these codes. Some developers like to solve the problem of large controller code by adding new view code. For example, if an application has a table and a form, one controller usually manages the form and the other controller manages the form. Of course, there is no "absolutely correct" method to identify whether the code you are writing uses the correct logic controller code. But remember that the controller is used to interact with other controllers. In Example 3A, you can see how to retrieve the referenced object from another controller and call its function again. This. getController ('someothercontroller '). runSomeFunction (myParm); example 3A. obtain the reference of another controller and call its method. in addition, you can trigger an application-level event (that is, all controllers can listen to it. In Example 3B and 3C, you can see how to trigger an application-level event in a controller and listen to this trigger event in another controller. MyApp. getApplication (). fireEvent ('myevent'); example 3B. trigger an application-level event. myApp. getApplication (). on ({myevent: doSomething}); example 3C. another trigger is listening for events at the application level. note: After ExtJS 4.2, it is easier to use multiple controllers. Because they can directly trigger the events being monitored by other controllers.