Latest Contributions by Noah-Sager

This blog post is the third in a series of JavaScript debugging tips and tricks to help you on your way. See JavaScript Debugging Tips Part I  and also JavaScript Debugging Tips Part II for our previous segments. In the past two JavaScript Debugging Tips posts on the Esri Support blog, we looked at the Network Tab and the Console Tab as part of the Google Chrome Developer Tools. While most modern browsers have some form of developer tools, here we use Chrome for our examples. Our goal for this third blog post in the series is to introduce more advanced tips and tricks to enable you to more effectively debug and troubleshoot your JavaScript code. Specifically, we will focus on three areas: enhanced messaging to the console, better ways to set breakpoints using conditions specified at runtime, and a more efficient way of stepping through breakpoints in the Sources tab with a method called blackboxing.Part 1: Console.table Console.log is our primary debugging function, but this function's output can be a bit difficult to read (especially when viewing a lot of data). One way to enhance our console log messaging and view data more easily is to display a list of objects as a table, which is accomplished using the console.table function. This function takes one mandatory argument, which must be an array or an object, and one additional optional parameter. Each element in the array is a row in the table. Let’s take a look at the Console Table sample. 1. Open the Chrome Developer Tools by using shortcut keys (Windows: Control + Shift + I, and Mac: Command + Option + I), or by navigating to the top right-hand pane of the browser, clicking the three grey vertical dots, and choosing “More tools” > “Developer tools”. 2. Select the console tab. 3. Click “Perform Query” in the sample application. This performs a query task to view all counties in Connecticut. The code uses the console.table to print the results in a table as shown below. console.table Every row in the table shows all attributes for a specific county. Next, we use the console.log to compare the console.log and console.table. This function will print a line with an array of objects. console.log Once we expand the array, we can view the objects in a list. console.log expanded To view the attributes, we must expand the objects in the list. console.log expanded with attributes While we can access the attributes of one feature when using console.log, we can view all attributes for all features at once using console.table! The image below shows both functions in the console window. console.table & console.log Part 2: Conditional Breakpoints In JavaScript Debugging Tips Part II, we talked about setting a breakpoint in the Sources tab, refreshing the application, and pausing the application at that line of code. This is a great way to examine your code and how functions are called, and where potential areas of trouble could arise. However, sometimes we don’t want the breakpoint to be reached every time. Sometimes we only want the breakpoint to be reached if certain conditions are met. While we could write some logic code in the form of a loop to check for values, there is an easier way to do this at runtime. For example, let’s look at a sample. 1. Open the Edit Features sample and the Chrome Developer Tools. 2. Navigate to the Sources tab, and left-click line 301 to set a breakpoint there. 3. After the breakpoint is set, right-click the breakpoint and select “Edit breakpoint…”. Edit Breakpoint Note: We could also get here by first right-clicking line 301 and selecting “Add conditional breakpoint…”. Add Conditional Breakpoint 4. Set a condition whereby the breakpoint will be reached only if the user inputs “test” into the “Contact:” field when updating a feature. Here is the code: editFeature.attributes["Incident_Address"] == “test”Note: We do not want to use "=" because this assigns a value and thus always returns true, so we must use "==". Breakpoint Expression 5. If we input “test” for the “Contact:” and click “Update incident info”, the breakpoint will be reached and the application pauses. Condition Met These conditional breakpoints can be useful for testing when you want to ensure data is sent back to the server correctly, or for error handling when you want the application to pause so you can inspect the object(s) of interest rather than letting your error handling code take over.Part 3: Blackboxing While setting breakpoints is a great way to make friends and go through your code, this process can occasionally kick you out of the file of interest and into another source file or into a third-party JavaScript library. For example, let’s look at a sample. 1. Open the Query SceneLayerView sample to follow along (this is similar to the sample found on developers.arcgis.com). 2. Open the Chrome Developer Tools, select the Sources tab, and left-click line 49 to set a breakpoint. 3. Refresh the page so the debugger pauses on line 49. From here, a "Paused in debugger" message appears (next to a "Play" button and a "Step Over" button). See below for a screenshot. Paused At Line 49 4. If you click the "Step Over" button about five times, you exit out of the main .html file and into the init.js file of the ArcGIS API for JavaScript. You can explore the init.js file, but we want to focus on the code that we wrote. Click the "Play" button to get home safely. Debugger in init.js file Enter blackboxing to save the day. Blackboxing is a method to exclude files and libraries from the debugger, so that your focus remains on your file(s) of interest. Let’s take a look at how we can blackbox the ArcGIS API for JavaScript library so we can just step through the main file of interest. 1. With the Developer Tools open, click the three vertical dots in the far right-hand pane of the window and select Settings. Developer Tool Settings Developer Tool Settings 2. On the left-hand side of the window, click “Blackboxing” to open the “Framework Blackbox Patterns”. Blackboxing 3. Click the “Add pattern…” button, and enter this framework pattern: js.arcgis.com.*\.js Blackboxing Pattern 4. Click “Add” and check the box above the pattern input to “Blackbox content scripts”. 5. Close the Settings window and return to the Sources tab. 6. Refresh the page so the debugger pauses on line 49. 7. If you click the "Step Over" button about five times, you exit out of the main .html file and into the debugger:///VM file (this is an empty function which you can safely ignore, or read more about here), as well as complete one more "Step Over" operation into the application. Now rather than debugging unnecessary, ancillary libraries, you can focus on debugging the code you wrote or are trying to understand. One last point worth mentioning is that blackboxing applies to the browser, not just to the webpage or web app of interest. After testing completes, feel free to remove the blackboxed pattern(s) to ensure a conventional web browsing experience. This concludes our blog about advanced tips for using the Google Chrome Developer Tools with examples from the ArcGIS API for JavaScript. We hope you found the above tips useful and entertaining. For more information about debugging tips with JavaScript applications, here are a couple additional resources from the past several years:Additional Resources Useful Javascript debugging tips you might not know (2015) Javascript debugging tips using the Chrome Dev Tools, deb.js and more (2015) (Mozilla) Introducing debugger.html (2016) Debugging with the JavaScript debugger (2017) Blackbox JavaScript Source Files Join us next time as we continue to delve ever deeper into Developer Tools and learn some valuable lessons. Happy debugging!</span> Artemis F. and Noah S. - Esri SDK Support ... View more

This blog post is the 2nd in a series of JavaScript debugging tips and tricks to help you on your way. See JavaScript Debugging Tips Part I – Google Chrome and the Network Tab for our first segment. The most enjoyable part of any programming assignment is right near the beginning when you sit down with a pile of tools and resources and start hammering away at raw clumps of code. The more difficult part comes when you attempt to launch the application, only to watch that tightly-written code unravel into multiple late nights staring at a computer screen. However, all is not lost, as we have an excellent recommendation for you, which is the subject of this blog: the Console tab inside your favorite browser's Developer Tools. If you’re feeling upset or emotional, the Console tab is the perfect choice for you. Maybe someone in your family is dealing with a difficult time, and could use some cheering up. Consider the Google Chrome Console tab (gluten free options are available). Users who like the Console tab might also enjoy the ArcGIS API for JavaScript. I obviously do not understand homographs As we wrote in Part I, accessing the Chrome Developer Tools is easily done using shortcut keys (Control + Shift + I) or by navigating to the top right of the browser, clicking on the hamburger and choosing “More Tools”, then “Developer tools”. Once the Developer Tools are open (other Developer Tools are available in other browsers), there are several Tabs that become accessible to you. Here we will focus on the Console. If you want to open the Console tab in Chrome Developer Tools directly, use this keyboard shortcut: Control + Shift + J (the “J” stands for jocular). For more neat tips, please check out the official Google documentation about Chrome DevTools: Using the console. The Console is used for two purposes: 1) to display logged information from an application's JavaScript (usually during application development), and 2) to interrogate objects and execute JavaScript interactively. In this blog, we will look at both kinds of examples, and elaborate on some additional tips and tricks that we use in Technical Support. The first thing we can do is to add some “console.log” statements inside our application. We will take a modified sample, hosted on GitHub, which can be found here: Sample Console Application. Feel free to follow along at home. At lines 60-62, and again at line 66, we’ve added some of those “console.log” statements to display information about our Feature Layer. Our use case is that we are creating a web mapping application, and during our testing, we want to ensure that the data we are consuming from ArcGIS Online is the correct data to display on the map. To this end, we print out a few choice pieces of information about the Feature Layer: the title of the layer, and the URL of the layer. Since I do not know the syntax for the URL property, I use “URL” and “url” as seen below. JavaScript console.log statements Here is a screenshot of the output of the “console.log” statements. We see the relevant information we were expecting. Also, please note that the output for “featureLayer.URL” is “undefined”. This is because items in the console are case sensitive. The valid property is “featureLater.url”, and invalid properties do not throw an error, and instead return an undefined result. This can be a tricky thing to trap, but later on in this blog we will look at some tips for dealing with this sort of issue. JavaScript Console Output from console.log With the Console still open, let’s try entering the same property values from the code: featureLayer.titlefeatureLayer.URLfeatureLayer.url Notice that all of these properties now return an error, instead of an actual value (or even “undefined”). This is because the local variables are no longer in scope after the app is initialized, so even the “featureLayer” object cannot be recognized.  Here is a screenshot of the output of the new console statements. JavaScript Console Output after App is loaded If we had made “featureLayer” a global variable, we would then see “undefined” returned for the object in the Console (variable is known, but the details are still not accessible). The point is: only variables that are in scope can be interrogated in the Console. So can we use the Console interactively and type in property values? Let’s find out. The next thing we can do to our sample app is to add a “debugger;” statement in the code. We will take another modified sample, hosted on GitHub, which can be found here: Sample Console Application 2. Feel free to follow along at home. At line 60, we’ve added a “debugger;” statement to help display information about our Feature Layer in the Console. JavaScript debugger statement How does this statement work? Click the link to run the application. Then, open the Developer Tools (Control + Shift + I or Control + Shift + J), and refresh the application. The application should pause, and you should see a “Paused in debugger” message at the top of the screen, and the “debugger” line highlighted in the Sources tab: Paused in debugger 1 Now, with the application paused, we can go back to the Console tab, and try interrogating the featureLayer properties again. Here we see that we have proper scope to the variable and we can see the output: Paused in debugger 2 Cool, right? Let’s look at another option, similar to “debugger”. Back to the Sources tab, notice the line numbers to the left of the code. If we left-click on a line number, we can set a breakpoint, which will have the exact same effect as writing “debugger” in the code. Left-click on lines 56, 62, and 66 in the same application, then refresh the application. Breakpoint 1 The application pauses immediately at the first breakpoint. Now, we could go back to the Console tab and again inspect variables and properties to our heart's content. Not only that, by clicking the curved arrow to the right of the Play button at the top of the screen, we can step through our application and watch the excitement as we see how the code executes step-by-step. Or, we can click the Play button at the top of the screen, and let the application run to completion, or to the next breakpoint. Breakpoint 2 And another Play button click brings us to the next breakpoint. Breakpoint 3 The point of this blog is to highlight the usefulness and functionality of the Console, but we do want to point out another usage of setting breakpoints here as well. Breakpoints allow the developer the ability to see the order in which asynchronous code executes, how functions are run and what parts get skipped or fail. For more information about debugging tips with JavaScript applications, here are a couple additional resources from the past several years: Advanced Debugging With JavaScript (2009) Debugging JavaScript with Chrome DevTools Breakpoints (2016) JavaScript Debugging Tips Part I (2014) In this installment, we learned how to access and use the Console tab inside Chrome Developer tools to reveal the properties and values of variables and objects in our JavaScript code. This information can greatly facilitate the debugging and coding of a web-based application. This concludes part two of a multi-part series on JavaScript Debugging Tips. Join us next time when we delve even deeper into some Developer Tools, and we all get raises. Happy debugging! Noah S. and John G. - SDK Support Services ... View more

Wrote a new blog about getting more comfortable with the ArcGIS API for JavaScript 4.0. If you're familiar with 3.x, this should provide a nice walkthrough about what's new and awesome at 4.0. https://blogs.esri.com/esri/supportcenter/2016/06/08/getting-comfortable-with-javascript-api-4-0/ ... View more

Now that the ArcGIS API for JavaScript 4.0 has been released for a couple of weeks, this is an excellent opportunity to take a walk through some of the new syntax and functionality. This blog will go through a sample 3D application focusing on the Search widget. You can follow along with the sample code from the Esri Developer Support GitHub repository, and run the hosted sample here: View it Live. Functionality-wise, the app displays a 3D map with four widgets: Search, Zoom, Compass, and Attribution. By default, the View includes the latter three widgets, as described in the documentation. If you’re not familiar with the 4.x changes, all mapping apps contain a map and a view. The map holds the data, and the view contains the visualization information for that data. In other words, the map is the subject, and the view is the camera; complete with filters, modes, and settings. All 2D apps will have MapViews, and 3D apps will have SceneViews (note: the term ‘scene’ indicates three dimensions across ArcGIS). The same applies for maps from ArcGIS Online and Portal for ArcGIS: a WebMap is 2D, and a WebScene is 3D. 2D map + 3D scene You can input a location in the Search widget and either select a result from the drop-down suggestions, or press Enter on the keyboard to go to the first place in the list. The view will zoom to that location and place a picture marker symbol on the map. If you open the Developer Tools in the web browser, you will see some helpful console log messages indicating the progress of the Search widget. In the code, there are many helpful comments describing the functionality, with links to references to find more information. The Map and SceneView constructors might be new, but they are very straightforward. What I want to focus on here are two things: the SearchViewModel (beginning on line 88), and the view.ui (beginning on line 117). One of the awesome features of 4.0 is the separation of the styling and the business logic. This means that widgets have a view and a ViewModel. The view is the widget itself and handles the display of the widget, while the ViewModel handles the properties and configurations. I should mention that we don’t have to use the ViewModel if we don’t want to since the ViewModel properties are also wired to the widget view. This was done for simplicity purposes. As an example, let’s look at the Search widget in the code: Search Widget and SearchViewModel The actual widget constructor was used for naming the widget and setting the visibility to true (default is true anyway). The SearchViewModel handles all the configurations that were set to customize the user experience and interface the way I needed (see the sample for comments). What’s interesting about this ViewModel system is because it's separated from the widget constructor, it’s now way easier to share business logic amongst widgets and code bases. Here is some more information about the SearchViewModel. The second interesting aspect of 4.0 I will discuss here is how we add the Search widget to the app. Let’s look at the code snippet from 4.0 and from 3.x. Currently, we can add the widget directly to the view’s user interface without creating a separate div element. This is an efficient (and dare I say, elegant) workflow. Add Search Widget 4.0 At the 3.x versions, we need to create a div element, reference the div when the widget is created, and reference it again inside the HTML body tag. Add Search Widget 3.x For more information about adding widgets to the view, you can reference this documentation. In summary, the ArcGIS API for JavaScript is a powerful product that leverages the power of GIS directly on your web browser. If you’ve been working with earlier versions of the API, reading the Transition to 4.x help document can get you going. And if you’re brand new, you can start with the Discover 4.x Guide. There’s a lot more to come as we continue to add functionality and awesomeness to the JavaScript API 4.x. Happy coding! Noah S. - SDK Readiness Lead ... View more

We are very excited to announce that the Web AppBuilder for ArcGIS (devloper edition) 2.0 Beta is now live on the Early Adopter Community website! Please check out our blog for more information and highlights about this release: Web AppBuilder for ArcGIS Developer Edition Now Supports 3D (Beta)!! | ArcGIS Blog ... View more

We are very excited to announce that the Web AppBuilder for ArcGIS (devloper edition) 2.0 Beta is now live on the Early Adopter Community website! Please check out our blog for more information and highlights about this release: Web AppBuilder for ArcGIS Developer Edition Now Supports 3D (Beta)!! | ArcGIS Blog ... View more