Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Easy to use service wrapper around esri-loader?

See original GitHub issue

Hi Guys, not really an issue…but more a request for guidance. I’m getting around to upgrading an angular app to cli 6.x and moving away from esri-system-js. It’s basically a map and some menus and has heaps of esri dependencies through out.

As such it would be a real pain to have to load modules using this pattern everywhere:

loadModules(['esri/views/MapView', 'esri/Map'])
.then(([MapView, Map]) => {
  // do stuff

Even using await it’s not so nice to have scattered everywhere. I’ve created a service to inject around that can encapsulate this and a list of modules I’ll want to load straight away or lazily. They’re in this gist -

This will allow creating a new arcgis object like so where the service is injected: let map = new this.esri.Map({ //whatever params// });

To lazy load:

await this.esri.load(["SimpleMarkerSymbol"]);
let sms = new this.esri.SimpleMarkerSymbol();

This seems ok-ish, the overhead is adding every module to the modules list and creating a property on the service for each module (for typings and ease of calling).

I can’t help but feel it’s a bit shit though…so before I crack on and rewrite a bunch of stuff wanted to check if you have any better ideas?? I have checked out the other issues in this repo - particularly this one,, which I think is similar, but not quite as succinct as I would have hoped.

Also any examples of using typescript 2.9 import() yet? Thanks heaps!

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

nickcamcommented, Jul 29, 2018

Hi @tomwayson - awesome, thanks for the detailed write up! Being used to the ease of import statements and instantiating from them might have spoiled me…the arguments against them are compelling though.

Maybe this app is a bit of rare case, but I know that I’ll need about 80% of the modules I want to use loaded up front just to get the initial view, the flexibility to lazy load when required is a cool thing to have up the sleeve though.

I thought about using void functions to expose/use the modules, and after looking at the example again I can see this app basically already does. Currently there’s multiple services that relate to a particular app function or area each that import esri modules and they contain the sorts of functions you have in your example, so there’s no esri module bleed into views or outside these services. “Theoretically” we could swap out arcigis api for something else…although in reality it’s not practical without basically rewriting the app.

Some of these services are quite involved and could probably be refactored (hindsight, lessons learned etc…), what I was hoping for was easier instantiation within these services by wrapping the loader with module defs to sit behind them. Also have some classes that extend esri modules, haven’t looked at refactoring those yet though so not sure how that will go??

Thanks for your help, plenty to consider as I go about refactoring this thing 😃!

tomwaysoncommented, Jan 31, 2019

Here’s another variant on the pattern I suggested above.

In your fn that calls loadModules() load all classes that your app needs to work w/ the map. Then resolve the promise w/ one or more fns that close over the map/scene view and the classes. Callers can then use those functions to work w/ the map. Here’s an example:

I have a newMap() fn that resolves with a refreshGraphics() fn after the map loads:

Then in the component that calls newMap(), it holds on to refreshGraphics() for later use:

Whenever that component receives a new array of items (JSON), it calls refreshGraphics().

For good measure I delete the map component’s refernece to refreshGraphics() before the component is destroyed:

Read more comments on GitHub >

github_iconTop Results From Across the Web

esri-loader - npm
A tiny library to help load ArcGIS API for JavaScript modules in non-Dojo applications. Latest version: 3.6.0, last published: 2 months ago.
Read more >
ArcGIS API for JavaScript: Building Apps with React - YouTube
... applications that integrate the ArcGIS API for JavaScript via @arcgis/core or Esri-loader. In this session, we'll use React to build ...
Read more >
Angular developers: how are you unit testing class...
The wrapper class exposes its own loadModules() method which can be easily mocked, eliminating HTTP requests to the ArcGIS CDN in a test...
Read more >
Using the ArcGIS API for JavaScript in Applications built with ...
angular2-esri-loader exposes an Angular 2 service that wraps the esri-loader functions in ones that return promises to make it easier to use ......
Read more >
esri-loader/ - UNPKG
The CDN for esri-loader. ... An Ember addon that wraps this library ... some applications and framework-specific wrapper libraries that use this library....
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found