The esri-loader library hit the 2.0.0 milestone this week. This release doesn’t add any features, but merely removes the old callback APIs that were deprecated when we introduced the promise-based ones in v1.5.0. If you’ve been using the new APIs, you can save yourself a few bytes by upgrading to 2.0.0. You can read more in the 2.0.0 release notes.
One does not simply load modules from the ArcGIS API
If your ArcGIS web application uses any other module loader besides the Dojo loader (i.e. webpack, Rollup.js, etc.), you should be using esri-loader.
In this post, I’ll explain the hack that underlies these solutions and explore the pros and cons of two patterns for loading ArcGIS modules in applications that are built with a module bundler. Although most of the examples shown use webpack, the same patterns can be applied to rollup.js as well.
Recently I’ve been developing custom widgets for the ArcGIS Web AppBuilder, and I have found that there is a lot of boilerplate code that you have to create for each new widget. I thought that a Yeoman generator would be a useful way to scaffold out the widget files, so I created generator-esri-appbuilder-js.
What It Does
The package contains a couple of generators that walk users through a series of prompts to gather information about a custom widget that they want to develop for the Web AppBuilder, and then scaffolds out the widget’s files.
In my former professional life, I used to do a lot of .Net development, mostly ASP.Net development focussed on whatever alternative to WebForms was available at that time – e.g. ASP.Net MVP (remember that?), ASP.Net MVC, ASP.Net Web Pages.
I’ve recently been playing with the grunt-amdcheck plugin to remove unused dependencies from AMD modules. It’s common for define statements in an AMD project to accumulate unused dependencies over time as developers refactor, and it’s a good idea to clean those up from time to time as unused dependencies can:
Make it harder to maintain your code
Cause the browser to make unnecessary asynchronous requests at run time
Beyond that, if you’re interested in the mechanics of testing mapping apps with any of the frameworks we cover (the Intern, Jasmine, Karma, etc) there are plenty of resources to get you going.
Last month I challenged myself to try make at least one contribution a day to GitHub for 30 days straight, and as a result I’ve been able to make long overdue updates to all of my existing repositories as well as make meaningful contributions to other peoples’ open source projects. Some of the things I accomplished during the challenge:
The challenge also helped me up my Git Fu a bit, since (sadly) most of my work projects are not managed in Git. If you’re like me, most of your GitHub activity takes place outside of your normal work hours, and this kind of challenge can really help you get to things that have been on the back burner for too long.
I’d definitely recommend others try a similar challenge. Here are my (self evident) tips for successfully completing your challenge: