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

Esri Technical Support is unlike any other Technical Support on the planet. But if you’ve ever opened a Support case before, you already know that. We provide world class support to our customers to help make them as successful as possible with our technology. But if you’ve ever come to one of our conferences or technical workshops, you already know that. However, what you don’t know may mildly surprise you. I would like to take this opportunity to shed some light on how Support works, and help make you both more successful and more effective with your troubleshooting. Excited Esri Support I wrote a totally rad blog post back in the day about what it feels like to work as a Support Analyst. It’s a pretty sweet job, and after two years, I still maintain the sentiment that Support is full of super awesome and intelligent people who kick serious butt and take great pleasure in helping our customers. Therefore, it might (or might not) come as a surprise that in Support we can’t (all) be GIS prodigies with experience on every product or subject matter. Sometimes we need to do a screen-sharing session so we can both look at the same product/documentation together. Sometimes we have to test offline and get back to you later. Sometimes we need a senior colleague to assist, or need to transfer the case to another analyst who is better suited for the specific technology/question. I know that this is a racy topic, but my goal here is to concurrently increase our transparency and your success. To paraphrase our ultimate goal: we want to help you. I would put the emphasis on “want” in that statement to make sure that our intentions are clear: we want to help you. We also love you. Actually, love is a strong word, so let’s just say that we really really like you. So, you know that we like you, you know that we want to help you, now the next step is to help us help you. But the question is, how? Support Analysts at Work First, we’re all human beings. We think and we feel and we try really hard. We’re also professionals, so we will do our best to help you, and at the same time, achieve our own personal/professional goals. That’s a pretty vague statement, right? So let’s look at an example. Someone calls in with a question about the JavaScript API. I answer the question to the best of my abilities, but not everything worked out the way we wanted it to, and the customer gives me a bad survey. This hurts my feelings, but I talk to my manager and my manager talks to the customer, and we all learn something. This is another good nugget of information: every single survey is read and considered. If you have kind words to say, say them - we love to hear them. If you are upset and feel that something went wrong and have strong words to say, say them - we need to hear them too. Remember, as technologically savvy as we are, we are still human beings and thus imperfect and also warm and cuddly and willing to learn. Second, when you call/email/chat to create a new Support case, we do our best to route you to the correct analyst. Our analysts specialize in particular areas of our technology, so not everybody knows everything. You may need to be rerouted to accomplish this goal, but just remember that we want to help you. We are proud to say that we are constantly working on refining and streamlining this process. Even though it’s not perfect, it’s always getting better. Kind of like a piece of software, case management is always being upgraded based on user feedback and experience. Also, when logging new cases, please include as much relevant information as possible, including specific product names and versions. Copy and paste is both of our friends. Test applications and screenshots are good buddies too. We also accept cookies. Support Celebrates GIS Day Third, you know how they say at the end of some commercials: “Prices and participation may vary”? Well, it’s the same with Technical Support. The prices of our services, such as a Support contract, Premium Support contract, or a Professional Services contract, do indeed vary. Our Customer Service representatives or Account Managers would be happy to review these options with you. With regards to participation, your participation is vital. We need to be able to have an honest conversation, and we need you to hold up your end just as we need to hold up ours.  If you leave to go on vacation, or can’t work on something, just let us know so that we can temporarily close the case and then reopen the case when you are ready to participate. Remember that we really, really like you, but without you, there is no case. Fourth, we maintain a standard of one topic or question per case. Why do we do this? For many well-intentioned reasons. For one thing, it’s good for our internal resources. We are able to track and research on past cases, and it’s quite helpful to have one question and one answer in each case in order to quickly find the information that we need to help future customers. Another reason is that we need to help all of our customers in a timely manner. If there is another question or issue that arises during the current case, we need you to create a new case that goes back in the queue so that the next available analyst can handle it. This way we always work on a “first come first served” basis, and we don’t (read: can’t) play favorites. Lastly, we do this because there must be a light at the end of the tunnel. These cases could drag on for longer than necessary if we don’t have a firm resolution timeline in mind. Support Analysts at a Hackathon Sixth (I skipped number five to save space), some of us use a lot of exclamation points in our emails and chat interactions. You may find this bizarre or annoying, but believe me, we are not being annoying! We are also not shouting or saying things emphatically. We just do it because it seems nice that way!! Seventh, we love closing Support cases. It’s a bit hard to explain, but when we’re given a problem, and we can figure it out and send someone on their way towards success, it feels so freaking good - you have no idea. And even when a case gets closed, we can still re-open it if something bubbles up down the road, or if you have a question about a topic that was covered during the case. Nothing is forever, not even closure. I write these words to help. Real life is about people trying to live their lives to the best of their abilities, so why should professional life be any different? We’re here to help, plain and simple. Maybe they do things differently on Mars, but here on Earth, this is what world class technical support looks like. And you’re a part of it. Support Analysts at a Another Hackathon Noah S. - SDK Support Analyst ... View more