Top 5 Lightning Debugging Tips

June 30, 2018 ~ Sara Morgan ~ 2 Comments

top5 This month I had the honor of speaking at Texas Dreamin’ 2018 . My topic was Lightning Performance and Debugging Tips for Developers. The talk was a combination of things I went over at last year’s Dreamforce talk about 5 ways to Build Lightning Fast Components and some new stuff I have learned recently about debugging. You can check out the slides here at Lightning Performance and Debugging Tips for Developers.pptx.

The new debugging tips include the following:

# 1 – Check Debug Mode Setting

Debug mode is what you can toggle to allow detailed debug messages to appear in your browsers console log and these messages can really help you not only to debug your components, but they sometimes feature important messages about performance.

For the debug mode, you want that to be enabled in development, so you can get those messages you need as you are developing. Just remember that in production, you want to make sure this is turned off b/c when it is enabled, it means that all the css and javascript that is downloaded to the client is not minified. This means it will take longer to download and longer for your components to render. That is why you do not want it enabled in production.

DebugMode

# 2 – Use the Salesforce CLI Linting Tool

This tip involves using a feature that is available with the Salesforce DX CLI. And in case you are not familiar with Salesforce DX, it is essentially just a set of tools that allow developers to really streamline the whole Salesforce development process through source driven development. But, the particular tool that I want to focus on now is the CLI or Command Line Interface because it includes a linting tool that lets you scan your lightning code and determine whether it is violating any anti-patterns that could be impacting performance or even just causing problems in your code. It will give you messages that explain what is wrong with the code and so you have a chance to address them.

In case you are not familiar with linting, this is just a process of scanning and analyzing code before it is executed to look for known problems. This is a very good proactive development practice to get into. You can get more info about this tool from this link here.

# 3 Use debugger and Dev Tools

If you want to trouble shoot problems as they are occurring in real time you are going to need to work with the browser developer tools, like what you find in Chrome. This next tip has to do with adding a line of code to your Lightning JavaScript code that will call the debugger statement. Doing this will actually pause the execution of your JavaScript and allow you to step through the code and look at the value of any variables you have. It is like setting a breakpoint in your code and you can see an example of it below where I have added it to the code for the createNewRace function.

To see this work, you will need to use your browser developer tools. Once you do, and you get to the place in your code where the debugger line is executed, you will see something like the following when it is paused in the debugger.

debugger2

To get more info about using the debugger statement, you can check out this URL which sends you to a video that was done by one of the Chrome tools technical writers where he walks you through using it.

# 4 – Use Lightning Testing Service

The next tip has to do with the tool that you may not have heard of since it is only in Pilot and that is the Lightning Testing Service. This is a set of tools, that is actually available as open source on GitHub and it allows you to create test suites that are used specifically to unit test your JavaScript code, such as what you see here.

You know how you have to write unit tests for your Apex server-side code, but there is not really anything for testing the client-side? Well, this is it. Test suites can be written in Jasmine or Mocha or you can create your own wrapper if you are using some other test framework.

You can go to the URL you see here to see a great article that was written on the Salesforce Developers Blog about how to get started with it. And what you see here is just a listing of all the tests that are provided out of the box when you install the testing service.

It comes with 18 tests which get you started writing your own test suites. It is pretty easy to use and if you are serious about lightning development and want to create very stable apps, then this a must have tool for you.

# 5 – Use the Lightning Inspector Plugin

The last tip is to use the Lightning Inspector Plugin, which is a Google Chrome plug-in that you can install to tell you about what is going on under the covers for your Lightning components. Once you do you will have access to a new Lightning tab in the Chrome Dev Tools, which you may be able to see below. Notice the tab that is surrounded by a red rectangle.

I plan on doing another post soon where I go over in detail some of the great info you can get from this tool, But for now, I strongly encourage you to go ahead and install it. You can simply bring up the Lightning Experience in Salesforce and access your Developer Tools to check it out.

Top 6 Tips for Working with Lightning Testing Service

April 23, 2018 ~ Sara Morgan ~ 1 Comment

Lightning Testing Service (LTS) is a set of tools designed to help you test the JavaScript in abt your Lightning Components. Even though it is still in pilot, if you are developing Lightning Components, I highly suggest you take the time to check it out. Using this tool will be very important in ensuring that your components behave as expected.

As far as what LTS contains and how you use it, I suggest you refer to this Getting Started With Lightning Testing Service post by Christophe Coenraets from the Developer Relations Group. He does a great job of getting you started building your first test suite.

In this post, I will just highlight the super important things you need to know about working with LTS:

You do not have to install SalesforceDX to work with LTS, but I really think you are missing the point if you try to. SalesforceDX not only makes it much easier for you to work with LTS, but the thinking behind using SalesforceDX is very similar to why you need JavaScript testing. Testing your Aura methods with unit tests and manually testing your components is not enough to ensure that your lightning components are behaving correctly. It also does nothing to ensure that they will continue to behave correctly as you introduce more code.
Wrappers are ONLY provided for Jasmine and Mocha. If you want to use another testing framework, you will have to build your own wrapper, which will probably take you about a day to do. But, Jasmine is very easy to use and unless you are already using another JavaScript testing framework, I suggest you stick to Jasmine.
You do not install or use LTS in production. Seriously! This is just for development environments and even better it is for scratch orgs that you create using SalesforceDX.
LTS includes sample code to get you started. This includes not only the Jasmine and Mocha wrappers, but a Lightning App called JasmineTests.app that you can use to jump start your testing. Just follow the instructions in Christophe’s blog post and you should be up an running in no time.
You do have to create and upload Static Resources that contain the JavaScript code for your Jasmine test suites. But, SalesforceDX provides commands for doing this easily so it is not quite such a cumbersome process to replace code as you are doing your development.
This is the most important tip: Do not use LTS to test your server code. Keep your client and server-side testing separate. When calling Apex server methods that insert records with LTS, the data that is created is NOT rolled back. You have to be responsible for rolling back the data yourself. You can still mock the server call and an example of this is provided in Christophe’s blog post as Scenario #6. This is the recommended and best way for you to test the server code in your lightning Components. You can still create (and you actually still need to) regular unit tests to test that your Aura methods work as expected.

Ok, that’s it.

Hope it helps and good luck in your journey towards becoming an AWESOME Lightning Developer using Lightning Testing Service.

Initial Impressions of SalesforceDX

April 4, 2017June 2, 2017 ~ Sara Morgan ~ 1 Comment

Last year at Dreamforce, Salesforce’s Wade Wegner unveiled a new initiative called SalesforceDX, in which Salesforce promised to make the Version Control System the source of truth and NOT the Salesforce org, as it is now.

SalesforceDX represents a VERY different way of development.

As a former .NET developer, who has long considered the Salesforce tooling to be anything but robust and not in line with some of the more modern development tooling, I was VERY happy to see this new development. I waited anxiously to hear more, and early this year, Salesforce announced it was ready to go into the pilot phase. I immediately signed myself and my company, SynapticAP up and was graciously accepted.

This post represents a summary of some of my initial impressions while being part of the pilot:

The team has done a GREAT job of putting together a set of streamlined tools that I think were well thought out and elegantly designed.

I see this as something of great interest to ISV partners and large enterprises, but not sure how valuable it would be to small/medium sized orgs with low or simplistic code bases, especially since it will likely be an extra service they will have to pay for.

Even though the Force.com IDE uses the CLI, or Command Line Interface, it seems to me that the design team intended for you to use the CLI as your primary method of managing your scratch orgs. When SalesforceDX is released, I am sure other third-party IDE’s will jump on to supporting it, and perhaps the visual tooling will get better, but as it is, the Force.com IDE does not seem to do everything that the IDE does and I suspect it may always be that way.

SalesforceDX represents a VERY different way of development. To be quite frank, Salesforce has been doing things wrong for many years (in terms of modern development standards), but SalesforceDX represents an attempt to remedy that. If you are a developer that has only worked with Salesforce, or you started your career as an Admin and then transitioned to development, you may find SalesforceDX kind of strange at first. This does not mean it is bad, it just may take you longer to adjust to the way things are done with the version control being the source of truth and not the org itself. It represents a shift in thinking about your org, so don’t expect to make this transition overnight. Give yourself some time and eventually things will start to make sense.

I look forward to the eventual release of this product as I am sure it will really help to propel Salesforce development into the next whatever. If you have a chance to work with the pilot or the eventual beta release, feel free to share your thoughts here in the comments.