-
Notifications
You must be signed in to change notification settings - Fork 79
Easy to use service wrapper around esri-loader? #124
Comments
Our plan is to start using https://github.com/Esri/arcgis-webpack-plugin Currently it's anyone's guess as to when
I wish...still waiting to verify if Angular |
Ok fair enough, thanks @andygup! Will just use what I've got until things are updated. |
Actually, I consider it a significant benefit of esri-loader that it encourages you to:
The problem comes when you need to use something that really has no reason to be async (like a The key to success w/ that kind of pattern is to not overgeneralize, i.e. "adding every module to the modules list and creating a property on the service for each module (for typings and ease of calling)." Instead, focus on the specific workflows of your application. For example, let's say your app has a sidebar component that will need to at some point create a new addSymbolToMap(symbolJson) {
if (this._SimpleMarkerSymbol) {
const symbol = new this._SimpleMarkerSymbol(symbolJson)
// TODO: add the symbol to this._map, etc
} else {
// this should never happen, but just in case
throw new Error('map not loaded yet')
}
} Sure, it would be a pain to create such a wrapping function for every module, but if you focus on your app's specific workflows, I bet you'll find that you should only need it for a few modules/classes.
To clarify, that's @andygup's plan for https://github.com/Esri/angular-cli-esri-map - it's not "Esri's plan is to deprecate esri-loader once Angular get's it's act together." I'll admit that being able to |
Hi @tomwayson - awesome, thanks for the detailed write up! 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 :)! |
Here's another variant on the pattern I suggested above. In your fn that calls I have a Then in the component that calls Whenever that component receives a new array of items (JSON), it calls For good measure I |
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:
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 - https://gist.github.com/nickcam/162f3a375206737e5b5e42fc638c0fd8
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:
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, #71, 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!
The text was updated successfully, but these errors were encountered: