In previous chapters, we discussed the role of the architect as being one with many facets. From understanding client requirements to designing the code structure based on UI wireframes right down to coding standards and naming conventions, an architect will wear many hats during the lifetime of a project.
One of these hats is that of planning with knowledge of the technology at hand. In order to make sure that the users of a software platform have a responsive experience that won't result in frustration, we need to make sure that the design that's in place will load quickly and will promptly react to user input. With Ext JS, this means having an understanding of the right component to use at the right time, working with layouts in an efficient manner, designing your view model hierarchy to avoid overnesting, and so on. There are lots of things to consider.
Once the design is complete, there may be unexpected performance issues or bugs as development progresses. In these situations, the architect may take on the role of an expert problem solver, jumping in to apply their practical knowledge of the technology. Working with third-party developer tools to step through source code and profile areas of slow performance are key aspects to driving a project through to completion.
In this chapter, we'll cover these topics in the context of Ext JS and more:
- Working with browser tooling to debug and track performance
- Picking through the Ext JS source code
- Ext JS performance do's and don'ts
- Common pitfalls of Ext JS development
By the end of this chapter, we'll have the ability to work as project firefighters, jumping into situations that need fast, authoritative solutions before they spiral out of control.
We'll examine several features of the Developer Tools of the Google Chrome browser (firstly, stepping through code and debugging it). Why Google Chrome? Aside from the fact that it's my own browser of choice, its tools feel a little slicker than those in, for example, Firefox. Having said that, Firefox will allow you to do most of what we'll discuss in this chapter if you'd prefer to stick with Mozilla. At the time of writing this book, Chrome was at version 40, but most of these features have been around for at least a year.
During development, there will inevitably be situations in which we'll deal with code that doesn't work exactly as we'd expect, whether that's the code we've written, code from another member of our development team, or code in a third-party library (such as Ext JS).
When this happens, it's useful to be able to halt code execution and inspect the state of the application directly. This is exactly what the Chrome Debugger allows us to do.
Note
Documentation on using Chrome Developer Tools to debug JavaScript can be found at https://developer.chrome.com/devtools/docs/javascript-debugging.
We'll use the Alcohology app from Chapter 9, A Shopping Application, to show how a debugging session might play out.
Let's load up the Alcohology project in Chrome and navigate to a product, then pop up the Chrome Developer Tools by going to the View menu, then Developer, and Developer Tools. Select the Sources pane on the Developer Tools and you should end up with something like this:
The Alcohology app with Chrome Developer Tools
Let's imagine a theoretical situation in which something's not quite right when we add this product to the shopping cart. We'd like to drop into the code that handles the click event on the Add to Cart button, so in the left pane of Developer Tools, we use the file explorer to navigate to /app/view/product/ProductController.js and scroll to the onAddToCart method.
By clicking on the line number for line 54, a blue indicator appears to show that we have set a "breakpoint" in the code at the beginning of the onAddToCart method. When code execution reaches line 54, the debugger will pause execution and give us a chance to inspect the application state:
ProductController.js with a breakpoint (indicated in blue) on line 54
The breakpoint has been set, so the next step is to trigger the execution of this code and examine onAddToCart.
Clicking on the Add to Cart button will call the onAddToCart click handler and pause the execution on line 54. The whole line will become highlighted in blue to show the location we're paused on. This line of code grabs the current product from the view model and stores it in a product variable.
At this point, the highlighted line of code is yet to run and so the product variable will be undefined. Let's move on to the next line and examine the contents of product by clicking on the curving arrow in the right pane:
The "step over next function call" button highlighted in a red circle
This will skip the current line and move to the next, this time highlighting line 56 in blue.
At this point, the product variable will be set, so you can hover the mouse over it and a popup will appear showing its various properties and methods. As it's an instance of Alcohology.model.Product, which is Ext.data.Model, we'll see all of the properties and methods on the object provided by all of the classes in the inheritance chain.
Depending on the exact structure of the inheritance chain, some of these properties and methods will only be revealed by drilling down through the __proto__ property and expanding it.
Note
The __proto__ property is an internal property on a JS object that points to the prototype of this object. Ext JS replicates classical inheritance by using JavaScript's prototypal inheritance. You can read about this in more detail at MDN https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Inheritance_and_the_prototype_chain.
The line 56 looks like this:
this.getViewModel().get('cart').addProduct(product);Let's say we'd like to drill down into the addProduct method and investigate what's happening in here. The Step in to next function call button will let us do this (it's the downward arrow next to the Skip over button). The trouble is that it does exactly what it says, that is, steps into the next function call. Line 56 actually consists of three separate function calls:
- A call to
getViewModelthat returns the view model assigned to this view controller - A call to get with the parameter 'cart' that returns the cart from the view model
- Finally, the call to
addProductwith the product variable as a parameter
The result is that the first time we click on Step In, we'll end up in the Ext JS framework code for getViewModel. We then click on the Step Out upward arrow to return to line 56. Step In and Step Out again takes us in and then back out of get. Finally, on the third party of our little dance, Step In will take us into the source of the addProduct method:
Stepping in to the addProduct code
We can now examine how the product is used in this method and verify that the code is behaving as expected and if not, why not?
The repeated stepping in/out can be painful and confusing, particularly for new developers looking to use these advanced tools. As the problem-solving architect, we need to understand these quirks for both our own sake and to assist our team in debugging sessions. There are a couple of ways around this; we'll look at these next.
Chrome has a feature known as "blackboxing", which tells Chrome to bypass a code file when debugging. This is exactly what we need in order to avoid the step in/out dance we saw earlier; by blackboxing the Ext JS source, Chrome will not step into this code.
It's easy to set up blackboxing. Just use the left-hand side file navigator to open the Ext JS source code, which in development builds will likely be something like this:
/ext/build/ext-all-rtl-debug.js
We also opened this file earlier as we stepped through the code, so we have an alternative method of getting it open in the central pane. When we've got the file in question, it's a simple matter of right-clicking on it and choosing the Blackbox Script option from the menu:
The options menu for a source file with the Blackbox Script option highlighted
A banner will appear at the top of the pane to indicate that the file has been blackboxed. This is a great way to simplify debugging sessions. As the Ext JS source code is more than 100,000 lines long, it can also speed up the process a great deal.
Note
There are multiple methods of blackboxing a script. Refer to https://developer.chrome.com/devtools/docs/blackboxing for more information on the Chrome Developer Tools documentation.
The second method of avoiding step in/out pain is to bypass the code in question altogether. If we know the source of the method we really want to debug, then why not just set another breakpoint there instead? In our previous example, it would have made more sense to set the breakpoint on line 9 of Cart.js, right inside the addProduct method. By clicking on the Resume Script Execution icon, represented by a blue right-facing arrow, we could have jumped immediately from the breakpoint in the ProductController to the one in the Cart class.
There's an adage in software development: writing code is easier than reading code. Taking the time to work through and understand code that others have written is a key skill that all developers should acquire, but it's of particular value to architects who are often in the position of evaluating existing code and understanding how it fits into a bigger picture.
Debugging and stepping through code is a key part of this, tracing the execution of different paths to build a picture of how the application is behaving.