Introducing the Salesforce Lightning Inspector

As any professional web app developer knows, debugging your web apps is one of the most challenging aspects of the development lifecycle. In fact, one of the driving factors behind the emergence and popularity of Google’s Chrome browser in the developer community was its superior developer tools. But as good as those tools have become, challenges still remain – especially when working with apps that rely on DOM generation, such as apps built with Lightning Components.

With businesses increasingly looking to deploy beautiful user experiences across desktop and mobile devices, Lightning Components provide app builders with self-contained and reusable units that once created let you build cross-device applications lightning fast, with drag-and-drop tools. And now, to help improve your experience when developing Lightning Components, we’re proud to announce the all-new Salesforce Lightning Inspector!

The Salesforce Lightning Inspector opens up and improves your Lightning Component development, giving you access to a wealth of data about your running applications and components. With the Lightning Inspector you can:

Easily inspect and navigate the structure of your components
Identify performance bottlenecks by looking at a graph of component creation time
Debug server interactions faster by monitoring and modifying responses
Navigate the component tree, inspect components and their associated DOM elements
Track event firing and handling sequences

Want to get started? Install the Salesforce Lightning Inspector today!

Now let’s get hands-on with your new favorite tool

After installing the Salesforce Lightning Inspector, you’ll notice a new Lightning tab at the top of the Chrome DevTools.

As you can see, the Inspector itself is divided into six tabs:

Component Tree – inspect objects and values
Performance – identify which components are slower and why
Transactions – see the recorded state(s) during portions of the application
Event Log – inspect the events being triggered by code or user interaction
Actions – see and test the status of server-side actions
Storage – reveal client-side storage for Lightning applications

Please be aware that the Lightning Component Inspector is for use when developing Lightning Components, and as such, only works when viewing an .app or .cmp file.

Component Tree tab

Let’s start by looking at the Component Tree tab. This tab allows us to see the objects that make up our application, similar to the Elements tab in the traditional Chrome Dev Tools. However, the Component Tree tab gives us the ability to inspect the individual Lightning objects in their “code state” without the overhead of the rest of the DOM, while simultaneously allowing us to see the processed result of that code highlighted on the page. Additionally, as we select individual nodes, the current values for its Aura attributes are listed in a side panel. This is incredibly valuable as it eliminates the need to dig through the Network tab to find the return values for database or API calls — or even worse, using good old console.log(myData).

Performance tab

In the standard Profiles and Timeline tabs of the DevTools, we can see very general information about our Lightning apps, such as size, loading/rendering time and potential performance hot spots. However, this also includes the framework and DOM levels. But what we can’t see is any information about the individual pieces that make up the component. Using the Performance tab in the Salesforce Lightning Inspector, we can isolate inspection to just the component code, allowing us to identify which components are slower and locate where in the component hierarchy the slowness occurred.

Transactions tab

Using the Transactions tab, we can see the recorded state(s) during portions of the application’s execution. The transaction data includes the amount of XHR’s that were sent, the actions that were called, the time those actions took.

Event Log tab

A cornerstone of Lightning Components is its use of events and triggers. Up to now, in order to debug these, we’ve been left with debugger statements, breakpoints or the infamous console.log() statement. With the Event Log tab, we can follow along and inspect the events being triggered either by code or user interaction. In addition to simply seeing that “a button was pressed”, we can also identify the component that handled the event.

Actions tab

As we know, Lightning Components are client-side entities, and while we “know” that they are often interacting with Apex controllers – I mean, we wrote the code, after all – knowing if/when an Apex controller is queued, running or has completed firing has been basically a black box. Using the Actions tab of the Lightning Inspector, we can peer into the darkness and see the status of these server-side actions. In addition, we can even “test” the fault tolerance of our client-side component code by overriding and/or modifying server-side component results. For example, we might want to see what would happen if an action failed to execute, returned an error, or returned an unexpected value.

Storage tab

As any web application developer knows, one of the primary performance bottlenecks is the trip to the server. For this reason, we have the concept of stored actions. The Storage tab reveals the client-side storage for Lightning applications. Actions marked as storable are cached in the actions store. When a storable action is run it will use the value from the actions store if available. This can avoid a server trip altogether making your component run much faster. Using the storage tab you can see which actions are cached, the size of each cached action, and even where the cache lives.

Go forth and inspect

Looking for a place to get started with Lightning Component development? Once you’ve installed the Salesforce Lightning Inspector, here are some resources to help you on your journey:

About the Author

Greg Rewis has been passionate about the web ever since putting his first “home page” online in 1994. His career has taken him around the world – from a start-up in Hamburg, Germany, to the glory days of the web at Macromedia and Adobe, and finally to his role as Principal Developer Evangelist at Salesforce focusing on front-end technologies. When he’s not writing Javascript or CSS, you can find him dreaming about sailing his catamaran around the world.