Latest Contributions by JoelBennett

A new bug in 4.23 causes the MapView.zoom property to read incorrectly as -1 when the (1) constraints.lods and (2) extent properties are specified in the constructor. I noticed this new section titled “Zoom and LODs” appeared in the 4.23 documentation, but I’m not doing anything contrary to it to warrant this issue. To view this in action, go to the Sandbox for the “Into to MapView – Create a 2D map” sample. When there, change this code: const view = new MapView({ container: "viewDiv", map: map, zoom: 4, center: [15, 65] // longitude, latitude });   to this (it's a little long, but mostly just LODs): const view = new MapView({ container: "viewDiv", map: map, constraints: { lods: [ { level: 0, resolution: 156543.033928, scale: 591657527.591555, alias: "World (1:591,657,527)" }, { level: 1, resolution: 78271.5169639999, scale: 295828763.795777, alias: "World (1:295,828,763)" }, { level: 2, resolution: 39135.7584820001, scale: 147914381.897889, alias: "World (1:147,914,381)" }, { level: 3, resolution: 19567.8792409999, scale: 73957190.948944, alias: "Continent (1:73,957,190)" }, { level: 4, resolution: 9783.93962049996, scale: 36978595.474472, alias: "Continent (1:36,978,595)" }, { level: 5, resolution: 4891.96981024998, scale: 18489297.737236, alias: "Countries (1:18,489,297)" }, { level: 6, resolution: 2445.98490512499, scale: 9244648.868618, alias: "Country (1:9,244,648)" }, { level: 7, resolution: 1222.99245256249, scale: 4622324.434309, alias: "States / Provinces (1:4,622,324)" }, { level: 8, resolution: 611.49622628138, scale: 2311162.217155, alias: "Counties (1:2,311,162)" }, { level: 9, resolution: 305.748113140558, scale: 1155581.108577, alias: "Counties (1:1,155,581)" }, { level: 10, resolution: 152.874056570411, scale: 577790.554289, alias: "County (1:577,790)" }, { level: 11, resolution: 76.4370282850732, scale: 288895.277144, alias: "Metropolitan Area (1:288,895)" }, { level: 12, resolution: 38.2185141425366, scale: 144447.638572, alias: "Cities (1:144,447)" }, { level: 13, resolution: 19.1092570712683, scale: 72223.819286, alias: "City (1:72,223)" }, { level: 14, resolution: 9.55462853563415, scale: 36111.909643, alias: "Town (1:36,111)" }, { level: 15, resolution: 4.77731426794937, scale: 18055.954822, alias: "Neighborhood (1:18,055)" }, { level: 16, resolution: 2.38865713397468, scale: 9027.977411, alias: "Streets (1:9,027)" }, { level: 17, resolution: 1.19432856685505, scale: 4513.988705, alias: "City Block (1:4,513)" }, { level: 18, resolution: 0.5971642835598172, scale: 2256.994353, alias: "Buildings (1:2,256)" }, { level: 19, resolution: 0.29858214164761665, scale: 1128.497176, alias: "Building (1:1,128)" }, { level: 20, resolution: 0.1492910708899543, scale: 564.248588, alias: "Houses (1:564)" }, { level: 21, resolution: 0.0746455354449772, scale: 282.124294, alias: "Houses (1:282)" } ], rotationEnabled: true, snapToZoom: true }, extent: { xmin: -17576195, ymin: 2427634, xmax: -17573701, ymax: 2429488, spatialReference: { wkid: 3857 } } }); view.when(function () { alert(view.zoom); view.notifyChange("zoom"); alert(view.zoom); });   Then click the Refresh link at the top right of the page. You will see two alerts: -1 and (probably) 15. To see that this is specific to 4.23, go to the top of the code, and change the “link” and “script” tag urls to use 4.22 instead. After clicking Refresh again, you’ll receive two more alerts: 15 and 15.  This demonstrates that what once worked in 4.22 no longer works in 4.23. When I usually report these things, I try to show where in the API the problem happens, but I’m not able this time. However, I do have a workaround for AMD-based solutions with a locally hosted API. In esri/views/MapView.js, search for: this._set("ready",!0) and then replace with: this._set("ready",!0);this.notifyChange("zoom")   ... View more

Not listed in the breaking changes for the 4.23 release is that svg elements generated by the symbolUtils. renderPreviewHTML function now have their css display explicitly set to “block”. Previously this property was not set, and defaulted to the value of “inline”. As can be seen in the image below, this makes a substantial difference in how they’re laid out on the page, which the browser's Developer Tools help show: 4.22 vs 4.23 This image shows a custom symbol selector that allows a user to visually specify the value for a field associated with a UniqueValueRenderer when specifying a feature’s attributes. It uses a simple table where each cell is supposed to be center-aligned, but changes made to 4.23 throw it off. I can’t think of a good reason why every image generated by renderPreviewHTML should be displayed as a block. If we wanted to do something as unusual as that, we could do it ourselves by wrapping it in a div, or better yet, adding our own CSS selectors. To get around this now, though, we either have to add application logic to set it back to inline, or add a CSS selector with an “!important” rule, neither of which is desirable. Since we host a local copy of the JSAPI, I prefer just to prevent the addition altogether. The following shows how to do this for AMD-based solutions. Although the issue is found within the esri/symbols/support/svgUtils module, we made the change in the esri/widgets/Legend.js file since we use the Legend widget and it already contains a copy of that module. In esri/widgets/Legend.js, search for: {xmlns:"http://www.w3.org/2000/svg",width:C,height:G,style:"display: block;"} Replace with: {xmlns:"http://www.w3.org/2000/svg",width:C,height:G/*,style:"display: block;"*/}   ... View more