extract esriLoaderService to own package

[tomwayson]

Would like to create a packag (anuglar2-esri-loader?) that makes the esri loader service to any angular 2 app. This code is generic and reusable.

This could be kind of like an angular-esri-map for Angular 2 - w/o the reusable map components. Those could be built as their own repos (angular2-esri3-components and angular2-esri4-components) if someone really wanted to.

[TheKeithStewart]

@tomwayson, so, you are thinking that it would potentially be three separate repos?

• anuglar2-esri-loader: to load the ArcGIS library and modules
• angular2-esri3-component: a component that will create a map that using ESRI v3
• angular2-esri4-component: a component that will create a map that using ESRI v4

The two map components would probably then need to accept a configuration object similar to:

{
  center: [-118, 34.5],
  zoom: 8,
  basemap: 'dark-gray'
}

Does this sound about right?

[tomwayson]

Yep. That's it.

The main reason to do it that way is that the loader logic works the same for both versions 3 & 4, but components are tied one or the other.

The other reason is that in my experience maintaining angular2-esri-example and angular-esri-map tells me that developers are interested in both consuming and contributing to a shared repository of components. However, since I don't even use Angular (2 or 1) day to day and my main interest is helping developers overcome the challenge of getting ArcGIS API modules loaded, I plan to create and maintain angular2-esri-loader, but I'm not planning to create the others. That's just my suggestion of how developers can share components.

I don't even think this repo as is would consume angular2-esri3-components - the map is so ridiculously simple that the component doesn't do much worth sharing.

The components in angular2-esri-example might make a better starting point for a angular2-esri3-components library. This does raise an issue though - how can the component repos support both module loading patterns: esri-loader vs the one used in that app and established in esri-webpack-typescript? The good news is that all the components access the esri AMD modules through a shared service. The bad news is that that service doesn't use esri-loader to load those modules. The trick would be to figure out the best way to provide the ArcGIS API modules to the components - should you try to establish a convention where you expect them to be injected in route data using an established name (like we do in this repo right now)? That's not great b/c forces everyone to use the router and requires passing dependencies as positioned array arguments 🙁. Or do you force everyone to use esri-loader since it's more flexible (allows lazy loading). Is there a smarter way to inject these dependencies that would allow either pattern? If I were to start a component repo today, I'd probably just steal the components there along w/ the map service and just adopt it to use esri-loader and if needed later on figure out how to support the other pattern.

[tomwayson]

Another, kinda radical, idea is that the component repos could use the import pattern from angular2-esri-map and expect that if you want to lazy load the ArcGIS API your app would use esri-loader and then use esri-system-js to register the modules before you consume them in the components or a shared map service. I'm not super keen on the complexity that adds, but it does make for a clean abstraction at the component level.

[tomwayson]

FYI - good related resources: http://blog.angular-university.io/how-to-create-an-angular-2-library-and-how-to-consume-it-jspm-vs-webpack/ https://medium.com/@OCombe/how-to-publish-a-library-for-angular-2-on-npm-5f48cdabf435#.ahuv2bt6d

[tomwayson]

One final note on library naming conventions: should check github and/or nmp to see if the results of this poll still hold true and use whatever is the most common prefix.

[tomwayson]

Searching the npm registry and github returned a lot more "angular2-" results than "ng-", though I'd say the ng-* results looked like they were mostly libraries. I decided to just stick w/ angular2- and I created https://github.com/tomwayson/angular2-esri-loader as a place to copy over the service from this repo.

[TheKeithStewart]

I found a solution for this that I believe will work well for folks that are using either the @types/core-js or @types/es6-shim packages (or neither). I submitted a pull request https://github.com/tomwayson/angular2-esri-loader/pull/1 with the fix.

[TheKeithStewart]

@tomwayson I've got a component put together that can be the angular2-esri4-component. Need to put the finishing touches on it and will get it up on NPM in the next day or so.

[TheKeithStewart]

@tomwayson I have now published https://www.npmjs.com/package/angular2-esri4-component. Please take a look when you get a chance. I'm starting to use this on a project so I will get a feel for how easy it really is to use. Once I've used it for a few days and feel that it is in good shape I can create one for esri3.

[tomwayson]

@kgs916 that is awesome!

Are you thinking that this library could eventually include other components like map, legend, layer list, etc? That's what I was suggesting above with angular2-esri4-components. However, it may make just as much sense to create a library per component as it appears you've done here for the v4 MapView. In the case of the latter though, my suggestion would be to use more descriptive name like "angular2-esri4-mapview" or "angular2-esri4-map".

[TheKeithStewart]

I see what you are saying, @tomwayson. Having each of the components separated into separate libraries would allow someone to pick and choose which ones they bring into their applications. However, these components wouldn't be huge and potentially tree shaking would help with this anyways. I'll move towards renaming the library to angular2-esri4-components and plan to expand the list of components available in it.

[tomwayson]

@kgs916 now that you've renamed, you should make a PR to this repo to use your <esri4-map> component. I assume it will be compatible w/ #19 now that JSAPI 4.1 can load webmaps.

[TheKeithStewart]

sounds good, @tomwayson. I should be able to have a PR ready soon.

[TheKeithStewart]

@tomwayson, as I'm working on adding in angular2-esri4-components into this example I'm considering changing the type of "lazy loading" that we are doing. Check out the below and let me know if you have any problem with going in this direction: https://angular.io/docs/ts/latest/api/router/index/Routes-type-alias.html#!#sts=Lazy%20Loading https://twitter.com/victorsavkin/status/797226263291138050?lang=en

[TheKeithStewart]

@tomwayson you can see what it will look like at https://github.com/kgs916/angular-cli-esri/tree/esri4Map. This isn't ready to be a PR as I'm still working on adjusting the tests but it functions correctly.

[tomwayson]

@kgs916

I took a look at it. Here are things I noticed:

1. angular2-esri-loader is no longer a direct dependency, as it is included in angular2-esri4-components, right?
2. the API is no longer lazy loaded in the route resolve, but in the component's onInit

One advantage of doing the lazy loading in the component is that it should be easier to show a loading indicator, as I discovered in esri-react-router-example.

Beyond that, I don't really have time to dig into the differences in the Angular 2 resolvers, etc. I'll assume you're following Angular 2 best practices.

Once you PR I'll have the others weigh in as well.

[TheKeithStewart]

@tomwayson You are correct about angular2-esri-loader being a dependency of angular2-esri4-components. However, I just added it back in as a direct dependency of the esri-angular-cli-example as well so that the version of the loader could be managed locally rather than having to rely on the version being updated on the external library.

I'm submitting the PR now and will address the rest of what you have mentioned there.