Latest Contributions by TomWayson

I don't use webpack (I develop in Ember day to day), so I can't diagnose your problem just by looking at your config. I can tell you what my approach would be if I were you. fork the repo that's closest to what you want to do (I'm guessing GitHub - dcworldwide/esri-webpack: Demo app to build typescript apps using ESRI's JSAPI with webpack) follow the build instructions to get it working before you make any changes start adding whatever you need that is missing from that repo If you get stuck, you can reach out to the other authors of those repos. They are much more likely to be able to help out if you can point them to your fork so they can pull it themselves and it out. At some point, you'll decide if you are going to keep using that repo as a foundation for your project, or you'll realize what changes are needed to make your current app work.  It is much easier to build up from something that is already working and find out what changes cause it to break than it is to start w/ something broken and try to get it working. I regret that I cannot be of more help than that. ... View more

I haven't looked in detail at your above code, but have you looked into the way these repos use the ArcGIS API for JavaScript with webpack? React/webpack/typescript: GitHub - dcworldwide/esri-webpack: Demo app to build typescript apps using ESRI's JSAPI with webpack  forked from (no react): GitHub - lobsteropteryx/esri-webpack: Demo app to build typescript apps using ESRI's JSAPI with webpack Angular2 webpack: GitHub - tomwayson/angular2-esri-example: Example app using the ArcGIS API for JavaScript v3 in an Angular2 app  Essentially they: configure webpack to exclude the esri and dojo modules output the ES6 code as AMD modules that can be loaded by Dojo include the ArcGIS API on the page from the CDN as a script tag There's some good discussion of (the apparent lack of) any limitations to this approach: Question: Any limitations? · Issue #2 · lobsteropteryx/esri-webpack · GitHub  Generally speaking, when writing ArcGIS API for JavaScript apps in ES6, I'd say that you are not "loading AMD modules in an ES6 way." Instead you writing ES6 modules and transpilling them into AMD modules that can be loaded by Dojo. In my experience, I've had the most success w/ approaches that exclude the Esri / Dojo from your local build and just output code to AMD that can be loaded by the CDN hosted ArcGIS API for JavaScript. I have another example that uses Rollup instead of webpack, but it's exact the same idea: GitHub - tomwayson/esri-rollup-example: Example application using Rollup to bundle local ES2015 modules that use CDN hos…  HTH ... View more

The purpose of using a subwidget is to create a widget that you can use both in the WAB and outside the WAB in another JSAPI application. If you do not need to do that, then it may not be worth the additional effort. Either way, I'd consider it more of an "advanced" technique, and probably not a good starting point. ... View more

To add some context, when I developed that tutorial, we were trying to unit test widgets, so the average `define()` block had about 10+ dependencies from dojo, dijit, esri, etc. That would be too much to mock. A better pattern would have been to isolate the business logic code into utility modules with few or 0 dependencies, which would be easier to test in isolation via mocks. Confusingly, the utility modules I used as examples in that tutorial actually would be a good candidates for mocking, b/c they have so few dependencies. If I were to go back and do it again, I'd do one example of testing a widget w/o mocks, and one testing a utility module w/ mocks. I'm not actively developing that tutorial any more, but PRs are welcome! In an angular application, I would advocate mocking all the time. First, I'd expect that the only AMD modules you're loading are esri modules for the mapping functionality, b/c for all other functionality (DOM, arrays, etc) you're probably relying on Angular. Angular makes it easy to mock those thanks to DI and ngMock. So you should only have to mock only the esri modules needed by each of your own modules. That way your tests never have to call Dojo's `require()`, so you don't need karma-dojo, or any other means of loading Dojo modules. HTH ... View more

If that were a real app, and not a demonstration of how to use karma-dojo to actually load Esri modules instead of mocking them, then yes, the best practice would be to have mocked Polygon there. Sent from Outlook Mobile<https://aka.ms/blhgte> ... View more

Good question! The true purpose of the esriLoader is to wrap dojo's `require()` in $q promises, which automatically handle updating Angular's digest cycle to notify Angular that something async has happened, namely that you got the esri modules you requested and that you exectued some code in a callback or `then()`. In terms of testing, I would say that you should be mocking esriLoader and/or the modules it would return and only test your own code. You can use karma-dojo the way I have karma configured here to actually load the modules, but I would advise against that. I may be less work than mocking those dependencies, but it introduces external dependencies and complexity into your tests that will make them slower and less reliable. ... View more

without looking into the code, I'd suggest calling .startup() on the grid after the modal is .shown() - grids (and many dojo comopnents) don't won't update their UI if they in a hidden container (i.e. a non-active tab, or a modal dialog that is not displaying) and you need to force them to redraw once they become visible. ... View more

Well Junshan Liu​ is one of the core developers of the WAB, and since he "suggested" that approach in the above forum post, it's now the "suggested way." ... View more

You should also be able to use the jQuery or order loader plugins in the define() block of your widget. I have not tried those personally, but in theory that should be a more maintainable solution b/c you would not have to modify index.html or init.js for each app you want to use this widget in. I don't see any docs on how to use these, but they can be found in: \jimu.js\loaderplugins The idea is that you pass the URLs to jQuery and plugins as a comma separated string as follows: define(['jimu/loaderplugins/jquery-loader!./jquery/jquery-1.7.1.js, jquery/jquery.showLoading.js']. function($) {...}); Alternatively, you could also use Dojo Bootstrap - I have an example of how to do that here: tomwayson/web-appbuilder-bootstrap · GitHub ... View more

Glad you figured it out - you probably learned more by doing it on your own. Sorry, I don't know that basemap gallery example off hand, both of the apps I've posted use a bootstrap drop down to enable basemap switching - not the basemap gallery. If it really was a dijit tooltip then you may need to add a dijit theme to the page (yuk!) in order to see it. However, to me it looks like our default Basemap widget just uses the thumbnail image title attribute to show the title, which should work fine regardless of your UI library (Bootstrap, Dijit, whatever). See: http://developers.arcgis.com/javascript/samples/widget_basemap/ ... View more

Ah, I see. You might try changing that page so that it loads the Esri CSS after the Bootstrap CSS. That's how the demos on the Bootstrap Map page are configured. I wonder if that would make it so that you would not have to remove Bootstrap's tooltip code. ... View more