While it’s not related to debugging, it’s also noteworthy that we ship heavy JavaScript transformations for older browsers, like IE11. That way you can use modern JavaScript and actually don’t have to care what browser your users are using.<\/p>\n
Minified JavaScript<\/h3>\n
Minification means that we compress JavaScript into as few bytes as possible by removing any unnecessary characters and elements like line breaks, whitespace, tabs, code comments and so forth. This reduces the overall traffic that’s required for sending a file to a browser. Minifaction also changes the names of functions or variables, for example Without any special setting, you can use the pretty format option in Chrome DevTools (or similar counterpart in your preferred browser) to get some sort of code formatting. This doesn’t give you full readability because of the changed names of variables and functions, but it’s pretty decent for a first check. This code is already debuggable, which means you can set breakpoints, inspect values during runtime, and use Chrome DevTools to work with the debugged values.<\/p>\n \n\t\t\t \n\t\t\t Note, that you see in the GIF already the location of custom Lightning web components in the Source<\/i> tab – it’s Next, we proxy certain things, like data that is provisioned via decorators (@api, @track, @wire). Some of that is to be considered read-only, like @api and @wire decorated properties. By using JavaScript Proxies<\/a> we make sure that they stay read-only. And for @track decorated properties, we use proxies to observe data mutation. This also means that you only see the Proxy object and you either have to use something like \n\t\t\t \n\t\t\t Now, you already get some<\/i> good debugging information in production mode. But what if you want the real cool stuff? Let’s take a look at that.<\/p>\n Besides production mode, you can enable debug mode for specific users. Debug mode gives you a few things, and particularly a few things that were not available previously for Aura components:<\/p>\n You can read more about debug mode and how to enable it for users in the Lightning Web Components documentation<\/a>. You can also use Salesforce CLI to create a new user in a scratch org with debug mode enabled using this command:<\/p>\n More information on how to use the Real exciting is that we ship unminified JavaScript in debug mode. What you get in the browser is what you coded (at least in JavaScript + CSS). The mapping from what’s in your IDE to browser is close to 1:1. That’s pretty cool, right? Especially in longer JavaScript classes you don’t have to guess, or remember, what variable \n\t\t\t \n\t\t\t A tip on debugging data that you receive via decorated properties (@api or @wire): if you bind the decorator to a property you won’t currently be able to debug it. In case you see some behavior that you need to debug, change the property to a function (for @wire) or to a setter (for @api). Then you can debug based on the deconstructed As you recall from the previous section, we’re using JavaScript proxies to enforce that certain types of data are read-only. To simplify the readability for you, we’re shipping a custom formatter in debug mode for these proxies. That means you won’t see the proxy object in Chrome, but instead the real value. We’re basically unwrapping the visual aspect of the proxy (but it’s still proxied, so no chance to modify the data, ok?!).<\/p>\n \n\t\t\t \n\t\t\t The third feature we’re shipping for helping you to better debug your Lightning web components are \u201cLWC engine\u201d warnings. In debug mode the Lightning Web Components engine actually identifies bad patterns that are only detectable during runtime, and then prints them as console warnings.<\/p>\n \n\t\t\t \n\t\t\t It’s a best practice to develop your Lightning web components in an org using debug mode. That way you see if your code can be even more improved while you develop.<\/p>\n There’s one caveat at the time of this writing: you’ll likely see other console warnings from the LWC engine on the console, as we with the initial release don’t filter on your own namespace. Because of that, you see other warnings for things like base Lightning components. Also note that in the current version of the filter in Chrome DevTools has no effect on the logged warnings themselves. Some of the warning messages are also obsolete and will be removed soon, like The best way to actually filter for only your own components is to remove the \u201cinfo\u201d log level which hides the stack traces.<\/p>\n This doesn’t mean that you should take a break when your code hits an exception (although sometimes it’s the right thing to do). This means that you can \u2014 and should \u2014 leverage the functionality in your browser to pause JavaScript execution when an error is caught.<\/p>\n When having this feature activated<\/a>, you’ll find yourself in the situation that your browser will also halt on any exceptions that are not caused by your own code, but by ours. In that case, we recommend that you make use of blackboxing<\/a>, which is a feature available in Chrome and Firefox. Blackboxing allows you to define JavaScript files to be excluded from pausing, so you will only pause on your own exceptions.<\/p>\n Chrome allows to set regular expressions for blackboxed scripts. Using these two patterns (which you can add via Chrome DevTools => Settings => Blackboxing<\/i>), you will exclude most of JavaScript errors that may be surfaced by other (read: not yours) components.<\/p>\n All the information of this blog post is also available as a short walkthrough video in our newly launched Lightning Web Components Video Gallery<\/a>.<\/p>\n Lightning Web Components are not only based on modern web standards: they are also debuggable using standard tooling. While production mode gives you good capabilities for peeking into potential issues, the new and enriched functionality for debug mode makes the experience better. In one of the next releases (#safeharbor), we’ll iterate over the experience and will add new functionality like JavaScript source maps<\/a> to make debugging even easier.<\/p>\n If you want to learn more about how to use the Chrome DevTools, check out the documentation<\/a>. This website<\/a> also contains a lot of useful tips to make you even more productive with Chrome DevTools. Once you’re ramped up, you should try your newly gained knowledge by deploying one of the Lightning Web Components apps from the Trailhead Sample Gallery<\/a>.<\/p>\n Another important element that we haven’t yet discussed is how to actually unit test your Lightning Web Components functionality before you deploy them, so that you may not have to debug your code at all. We’ll cover that in an upcoming blog post.<\/p>\n Ren\u00e9 Winkelmeyer works as Principal Developer Evangelist at Salesforce. He focuses on enterprise integrations, Lightning, and all the other cool stuff that you can do with the Salesforce Platform. You can follow him on Twitter @muenzpraeger<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" You built your first Lightning web component, everything looks great in the IDE, but something is not working as expected in your Salesforce org. That’s the point where it’s important to know how you can debug Lightning web components. This blog post will show you the available techniques. Lightning web components in production mode Before […]<\/p>\n","protected":false},"author":3071,"featured_media":190096,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2528,2766],"tags":[2598,2586,2678],"coauthors":[],"class_list":["post-190088","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-integration-apis","category-tutorials","tag-february-2019","tag-lightning-web-components","tag-lwc"],"podcast_audio":{"audio_url":"","duration":""},"featured_image":"https:\/\/d259t2jj6zp7qm.cloudfront.net\/images\/v1549910120-trailhead_module_lightning-web-components-basics_jtkkt7.png?w=200","related_posts":[{"post":{"ID":201348,"post_author":"3687","post_date":"2024-04-30 09:00:47","post_date_gmt":"2024-04-30 15:00:47","post_content":"Security is one of the most critical elements of storing your data on a device. We\u2019re excited to announce that in Spring \u201924, Salesforce is introducing the BiometricsService<\/a> mobile capability! BiometricsService enables developers to add additional security measures to the data being stored on Lightning web components (LWCs).\r\n\r\nLet\u2019s say, for example, that you are looking to build an LWC to store sensitive data, such as a contact\u2019s physical address and identification information. However, these are sensitive data points that you wouldn\u2019t want just anyone to have access to. Through BiometricsService, you will be able to use security measures, such as FaceID and fingerprint scanning, to add additional security to the data being processed within your Salesforce mobile apps.\r\n\r\nLet\u2019s take a look at how!\r\nconst mySuperVariable<\/code> can become const d<\/code> . Every Lightning Web Component JavaScript file that your browser receives from Salesforce in production mode is minified.<\/p>\n![\"\"](\"https:\/\/d259t2jj6zp7qm.cloudfront.net\/images\/v1549909394-minified_pretty_print_krzxhi.gif\")
\n\t\t\t <\/span>\n\t\t\t<\/p>\nmodules<\/code> (compared to components<\/code> for Aura components).<\/p>\nProxied values<\/h3>\n
JSON.stringify()<\/code> in Chrome DevTools (note: if you have an Object with circular references, it’ll throw when stringified), or you have to inspect the object structure itself.<\/p>\n![\"\"](\"https:\/\/d259t2jj6zp7qm.cloudfront.net\/images\/c_scale%2Cw_800-proxied_values_zmcojq.png\")
\n\t\t\t <\/span>\n\t\t\t<\/p>\nLightning web components in debug mode<\/h2>\n
\n
sfdx force:user:create -a mydebuguser UserPreferencesUserDebugModePref=true<\/pre>\n
force:user:create<\/code> command can be found in the documentation<\/a>.<\/p>\nUnminified JavaScript<\/h3>\n
d<\/code> was again \u2014 you’ll now see the name as it lives in your source code. And you can debug it, like you can do with minified JavaScript.<\/p>\n![\"\"](\"https:\/\/d259t2jj6zp7qm.cloudfront.net\/images\/c_scale%2Cw_800-unminified_snefw6.png\")
\n\t\t\t <\/span>\n\t\t\tNote that the JavaScript file in the browser also includes additional code, like transformed decorators or relative imports that got rolled up. Check out the video at the bottom to see more.<\/p>\ndata<\/code> and error<\/code> property.<\/p>\nCustom formatting<\/h3>\n
![\"\"](\"https:\/\/d259t2jj6zp7qm.cloudfront.net\/images\/c_scale%2Cw_800-custom_formatter_aghy0l.png\")
\n\t\t\t <\/span>\n\t\t\tCustom formatters aren’t enabled by default in Chrome, so you’ll need to set Chrome DevTools => Settings => Enable custom formatters<\/i>.<\/p>\nConsole engine warnings<\/h3>\n
![\"\"](\"https:\/\/d259t2jj6zp7qm.cloudfront.net\/images\/c_scale%2Cf_gif%2Cw_800-console_warnings_wzkn6r.gif\")
\n\t\t\t <\/span>\n\t\t\t<\/p>\nProperty \u201cxyz\u201d of [object] <\/code>is set to a non-trackable object, which means changes into that object cannot be observed (meaning you don’t have to care about that at the moment). And yes, we’ll improve that in the next few months (#safeharbor).<\/p>\nPausing on caught exceptions<\/h2>\n
\/aura_prod.*.js$<\/code>
\n\/components\/.*.js$<\/code><\/p>\nCheck out the video walkthrough<\/h2>\n
Summary<\/h2>\n
About the author<\/h2>\n
Work with the BiometricsService API<\/h2>\r\nBefore we discuss how to use the BiometricsService API, let\u2019s walk through a quick example of BiometricsService using Dreamhouse<\/a>, a sample app that features some LWCs for mobile use cases in a real estate context.\r\n\r\nSay that you\u2019re a real estate agent who has closed a deal with a client on a new home, and you are updating the Opportunity information in Salesforce. To process the transaction, you will need to collect the following paperwork and personal details on the Opportunity record.\r\n
\r\n \t
\r\n \t
Configure the BiometricsService API <\/b><\/h2>\r\nThe BiometricsService API enables you to verify device ownership when interfacing with an LWC. This can be done through two steps:\r\n
\r\n \t
lightning-button<\/code> base component. This will be used to prompt the user for biometric authentication.<\/li>\r\n \tStep 1: Configure your LWC HTML template<\/b><\/h3>\r\nFor this LWC, we\u2019ll use the
handleVerifyClick<\/code> onclick method call, which invokes the API we\u2019ll need to begin using BiometricsService on LWC. This onclick method can be housed in the lightning-button<\/code> HTML base component which, when invoked, will begin prompting the user for device ownership.\r\n\r\nTip:<\/b> When prompting biometric auth, you would want it to be a very upfront action for the end user trying to access the LWCs holding the aforementioned sensitive data. As such, a general recommendation is to house the lightning-button<\/code> component within a lightning-card<\/code> base component, which will render a card-style modal as a banner at the forefront for users when attempting to access sensitive data.<\/i>\r\n<template>\r\n <lightning-card title="Biometrics Service Demo" icon-name="custom:privately_shared">\r\n <div class="slds-var-m-around_medium">\r\n Use device biometrics capabilities to verify current user is indeed device owner:\r\n <lightning-button\r\n variant="brand"\r\n label="Verify" \r\n title="Verify device ownership using biometrics"\r\n onclick={handleVerifyClick}\r\n class="slds-var-m-left_x-small">\r\n <\/lightning-button>\r\n <\/div>\r\n <div class="slds-var-m-around_medium">\r\n <lightning-formatted-text value={status}><\/lightning-formatted-text>\r\n <\/div>\r\n <\/lightning-card> \r\n<\/template>\r\n<\/pre>\r\nOnce those HTML configs are set, you will get a view of BiometricsService running within your LWC. Here is a sample view of the HTML payload from above, running in iOS:\r\n\r\n![\"The](\"https:\/\/developer.salesforce.com\/blogs\/wp-content\/uploads\/2024\/04\/image-2024-04-29T143243.496-507x1000.png\")
\r\nStep 2: Connect your user interface with the BiometricsService API<\/b><\/h3>\r\nIn Step 1, we configured the
handleVerifyClick<\/code> method on the LWC in the HTML file. Here we will need to connect that method to the BiometricsService API that we import via mobileCapabilities<\/code>.\r\n\r\nYou can use the following API calls to interface with BiometricsService.\r\n