BLOG
|
This post is aimed at helping you decide when to use the new @arcgis/webpack-plugin or esri-loader in applications built with webpack. I've recently had the opportunity to put the new webpack plugin through it's paces, and I came away with the impression that Rene Rubalcava, Yann Cabon, and the team have taken an important step forward in making the ArcGIS API for JavaScript more interoperable with other JavaScript frameworks and build tools. TLDR: Scroll down to see the Conclusion. Rumors of esri-loader's demise have been greatly exaggerated So you may be wondering why would you ever want to use esri-loader now that we have the plugin? First, if you're not using at least v4.7 of the ArcGIS API for JavaScript, you can stop reading this and head right on over to the esri-loader documentation. It also goes without saying that if you're using another module bundler besides webpack (such as rollup.js or parcel) that the webpack plugin won't be able to help you and that you'll need esri-loader instead. If you're developing Ember.js applications, which use Broccoli.js instead of webpack, head on over to ember-esri-loader. Functional parity? Very close... Still here? Great! Before getting into the details, I should start by identifying the ArcGIS API + webpack scenarios for which there was previously no other workable solution besides esri-loader. These scenarios are listed from more common to more advanced: You do not have access to the weback configuration (i.e. you were using a framework's CLI tool) You want to lazy-load the ArcGIS API after the rest of the application was loaded and rendered You want to use the ArcGIS API in a server-side rendered (SSR) application Handles the hard stuff well I'm happy to report that the new webpack plugin handles the more advanced scenarios (lazy-loading and use in a SSR application) very well! For each of the plugin's two demo applications I was able to make a branch that demonstrates how to lazy-load the esri bundles using dynamic import(). Here are the relevant TypeScript and Babel commits. I also able to confirm that each of those branches had roughly the same initial load performance as their esri-loader equivalents. Importantly, using lazy-loading (with either the webpack plugin or esri-loader) resulted in a 4x decrease in the time it took to see anything other than a blank white screen. Stephen Sylvia expanded on that idea by creating a lightning fast (loads on a mobile phone on 3G in under 2 seconds) prototype that uses placeholder images for maps until the user wants to interact with them. Finally, I riffed on his work and created a branch that uses server-side rendering to demonstrate how you could optimize such a site for SEO. It would be easy to add a commit to that branch that leverages sever-side rendered Open Graph meta tags for rich social media sharing. Some work to be done However, these are still early days for the webpack plugin, and there are a few kinks to be worked out so that you can just use it in any webpack project. Specifically, at a bare minimum you need to be able to add it to the webpack config's array of plugins. The CLIs are getting better these days about letting you have access to the webpack config, but worst case scenario you may need to "eject" from the CLI in order to do so. You may find that even once you are able to add the plugin to your webpack config, some of it's settings conflict with those of other plugins added by the CLI. I had this problem when trying to add the webpack plugin to a create-react-app application. I poked and prodded a bit, and was able to resolve certain issues, but others were beyond my webpack fu (which isn't saying much). Coming soon... All in all though, I am confident that these incompatibilities will be worked out soon, and we'll have functional parity between the webpack plugin and esri-loader. If you're using the ArcGIS API with angular-cli, vue-cli, create-react-app, etc I hope you'll jump into the fray and try to help us figure out how to resolve these types of issues. So, which should I use? Let's say you've rolled your own webpack config (rather than starting from a CLI) and you can use either the webpack plugin or esri-loader in your app today. Why would you choose one or the other? Generally, I'd say that esri-loader makes it easier to integrate the ArcGIS API into a webpack application, because there is zero configuration. However it forces you into using complicated async patterns when working with 'esri' modules. In contrast, I'd say that the webpack plugin may be a bit more complicated to set up and configure, but once you do it offers more flexibility. Also, the webpack plugin does result in increased build times, but they're working on that, but coming from the ember-cli, I barely noticed. import and import() The biggest difference is that only the webpack plugin allows you to use import statements for esri modules. Instead esri-loader's asynchronous loadModules() API forces developers to consider the cost of loading esri modules and to use strategies that defer that cost by consolidating their use. This works well in applications that make very simple use of the ArcGIS API, such as a single map component. However this can become cumbersome in an application that has multiple components that work with the ArcGIS API such as a map component, a legend component, and a drawing toolbar, etc. Those types of applications will be easier to develop using the webpack plugin and import statements. However, if you want to lazy-load the ArcGIS API and it's modules (and if you're targeting mobile you should), you won't be able to freely use import statements anyway. Instead you'll end up grouping them into one or a few modules that you lazy-load with dynamic import() and you'll probably end up creating your own internal async API that looks a lot like that of esri-loader! Hopefully someday we'll be able to just use import statements for esri modules w/o either of these libraries and have support for things like tree-shaking of the ArcGIS API modules. To that end, the webpack plugin is more future-proof than esri-loader. Conclusion Here's a side-by-side comparison of the high level capabilities. Capability esri-loader @arcgis/webpack-plugin Works with ArcGIS API < v4.7 Yes No Works with other bundlers besides webpack Yes No "Just works" with any framework CLI or webpack plugin Yes Not yet Can lazy-load the ArcGIS API and it's modules Yes Yes Can be used in a server-side rendered application Yes Yes Can import esri modules No Yes Is future-proof No Yes When you look at that list, it becomes clear that that esri-loader is the versatile, backwards-compatible fallback solution, and @arcgis/webpack-plugin is a forward-looking link toward a brighter future. If you are able to give the plugin a try in your application I recommend that you do. If not, or if it doesn't work out for you, esri-loader will always be here for you.
... View more
05-10-2018
01:20 PM
|
2
|
0
|
3999
|
BLOG
|
It is now: GitHub - Esri/arcgis-webpack-plugin: Webpack plugin for the ArcGIS API for JavaScript
... View more
05-10-2018
03:35 AM
|
0
|
0
|
2316
|
BLOG
|
Until it's possible to build the ArcGIS API for JavaScript with another module loader/bundler like webpack you can always use esri-loader.
... View more
01-31-2018
02:42 PM
|
0
|
0
|
2316
|
POST
|
Jacob Wasilkowski had an idea on this that gives me an idea. I don't think it's correct to supply _both_ a callback, _and_ use the promise. Maybe something like this: ``` private GetTestQuery(where: string) {
return this.esriLoader.require(["esri/tasks/support/Query", "esri/geometry/SpatialReference"]).then(function (Query, SpatialReference) {
var query: __esri.Query = new Query();
query.outFields = ["*"];
query.returnGeometry = true;
query.where = where;
query.outSpatialReference = new SpatialReference(4326);
return query;
});
}); ```
... View more
03-15-2017
10:20 PM
|
3
|
1
|
726
|
POST
|
Just to make sure I understand this is TypeScript code using JSAPI 4.x in an Angular 1.x app, right? > I was expecting the GetTestQuery function to return a promise that would resolve to an esri Query object, but this is not what is happening. What _is_ happening? Does it get to your `console.assert()`? Have you tried handling the error side of the promise that's returned (i.e. changing line 19 above to }, (err) => { console.log(err); });`
... View more
03-15-2017
10:11 PM
|
0
|
0
|
726
|
POST
|
Heather Scroggins and mkaminow We've just deployed a second attempt at a fix for this. Please try again. Hopefully this resolves the issue for you.
... View more
12-20-2016
05:20 PM
|
2
|
2
|
1511
|
POST
|
OK, I've been able to re-reproduce the issue. Looks like the patch we pushed only fixed this under certain circumstances. I'm working on the fix now.
... View more
12-16-2016
08:35 AM
|
2
|
0
|
1049
|
POST
|
No, you should not have to. I've tried out test site and production, and I'm unable to reproduce the problem there. Are you seeing the _exact_ same behavior as above? If not can you please supply new screen shots and any additional information that we could use to troubleshoot this (i.e. any errors you see in the browser's console window, the url of your site, name of your organization, etc). Thank you.
... View more
12-14-2016
11:42 AM
|
0
|
2
|
1049
|
POST
|
The patch for this bug has been released. Please try again now Heather Scroggins.
... View more
12-13-2016
12:55 PM
|
1
|
4
|
1049
|
POST
|
Actually I was able to reproduce this behavior on another site. I've logged a bug and am working on it now. Will reply here when there is a status update.
... View more
12-09-2016
11:12 AM
|
2
|
5
|
1049
|
POST
|
Heather I'm sorry to hear that you're experiencing that. I was not able to reproduce this behavior. I created a new site, opened the Theme Builder, set my colors to as you show above. After clicking "Save" (not "Apply Changes") I see the following: This is a known bug that those changes aren't applied on the page unless you press the "Apply Changes" button, so I had to reload to see the changes take effect. After reloading the page, the "Theme Builder" panel looks like this: Currently, all values are required and default to #000000 (black), which explains why the Page Background Color and Link Color are set that way. However, the colors I input for Brand Primary Color and Text Color did persist as expected. Can you share anything else about your environment/data (browser, org, site, etc)? Thanks.
... View more
12-09-2016
10:30 AM
|
0
|
6
|
1049
|
POST
|
Just to add to what Rene Rubalcava said above, I would say that whether or not Esri releases an npm distribution of the JSAPI is not actually that important. It seems like many devs want an npm distribution is because they are using a module loader like webpack and a framework like angular2 or react where it is becoming more the norm to install libraries via npm than via bower. The thing is, an npm distribution isn't going to work any better in those situations than the current bower distribution, which is to say, it basically won't work with those tools until the issues with the dojo-webpack-loader are resolved, or until someone writes a similar plugin for Rollup.js or browserify, or whatever module loader you're using. Even then, I have my doubts about those bundlers ever being able to produce a smaller and/or faster build of the JSAPI than Dojo does. However, there are a couple of patterns you can follow to use the JSAPI in applications built with a module loader like webpack. I describe how those patterns work and why you'd use one or the other in Using the ArcGIS API for JavaScript in Applications built with webpack | Tom Wayson. You do not need to download/install the JSAPI (via bower or npm) to use those patterns. If you're using Dojo instead of webpack or other module bundlers, I don't see how getting the JSAPI via npm would be that helpful. In that case you probably want to base your app on either GitHub - odoe/generator-arcgis-js-app: Generator for ArcGIS JS API applications or GitHub - csnover/dojo-boilerplate: A starting point for developing with Dojo, which use bower and git submodules respectively. So, in my experience, how you get the JSAPI modules (bower, CDN, etc) isn't as important as understanding that you have to use Dojo (not webpack, not browserify, etc) to load them. If you prefer to write your application following the conventions of your framework of choice, there are libraries like ember-cli-amd, esri-system-js, and esri-loader that can abstract working with the Dojo loader, but you may find yourself in trouble if you don't understand that under the hood they're still using Dojo.
... View more
12-05-2016
10:18 PM
|
2
|
0
|
553
|
POST
|
It seems like you've been able to answer your own question, but I want to mention that there are now a few repositories on GitHub that demonstrate good patterns for using the ArcGIS API in React applications built with webpack. https://github.com/Robert-W/esri-redux https://github.com/davetimmins/create-react-app-esri-loader/https://github.com/tomwayson/esri-react-router-example https://github.com/davetimmins/create-react-app-esri-loader/ https://github.com/davetimmins/create-react-app-arcgis Unlike the example code shown in this question, these repositories don't rely on using the deprecated `esri` global, which does not work w/ v4.x of the JSAPI. If you want to understand more about how the patterns in those repositories work, I've written a blog post on using the ArcGIS API in applications built with webpack.
... View more
12-01-2016
10:20 PM
|
1
|
0
|
1729
|
POST
|
I'm glad that worked for you. However, I noticed what appears to be an error in the code I placed above, it should be `npm i -g yo`. Maybe that's what you did. Just mentioning it in case others come across this.
... View more
10-03-2016
10:13 AM
|
0
|
0
|
720
|
POST
|
What happens when you type in the following commands? npm ls -g yo
yo If yeoman is not installed, you'll need to run npm i yo
... View more
09-30-2016
06:58 AM
|
0
|
2
|
720
|
Title | Kudos | Posted |
---|---|---|
3 | 06-14-2024 11:41 AM | |
1 | 05-14-2015 09:58 AM | |
1 | 12-13-2016 12:55 PM | |
1 | 08-24-2016 10:39 AM | |
1 | 04-21-2016 11:22 AM |
Online Status |
Offline
|
Date Last Visited |
06-18-2024
05:16 PM
|