james-rae / pocgapi Goto Github PK

Files

Directories under src

• <root> has the loader stuff, code that makes the library, type defs
• map has the map stuff
• layer has the layer stuff
• util ? (not sold on the name) contains stuff like symbology, query, etc.

Module Interface

• .map or .maps provides functions to make maps. E.g.
  • gapi.maps.createMap(configObj, divId): Map
  • gapi.maps.createOverviewMap(mainMap, divId): Map (design up in the air, see #5 )
  • gapi.maps.create3DMap(configObj, divId): Map3D (next level enhancement)
  • thoughts on plural or singular for module name?
• .layer or .layers provides functions to make layers. E.g.
  • gapi.layers.createFeatureLayer(configObj): FeatureRecord (or whatever Records get renamed to)
  • maybe have it config driven? i.e. one function, derives layer type from config. might make typescript less great
• open to how the util-ish things are structured
  • current way would be gapi.query.myFunc(), gapi.symbology.otherFunc()
  • grouping might be more consistent, but means more typing. e.g. gapi.util.query.myFunc()
• a dev module for hackery? e.g. gapi.dev.esriLoadApi() to do plugin sorcery

Spam ideas below

Does Record and FC still make sense?

Would Layer and Sublayer be clearer? Maybe a better word than Sublayer...

Spam ideas here

The Overview Digit was dropped when ESRI moved to v4

Likely need to make a dedicated map view to handle it.

I guess using PanelAPI makes sense for the container? Would need to delay creation of the overview until the panel and the host <div> are created.

A second MapView would be easiest, however we might be seeing all layers in the view, not just basemap. Need to experiment.

Can also make a second Map alltogether and just keep it synched with our main map extent

Sample has a 2D overview on a 3D map.
https://developers.arcgis.com/javascript/latest/sample-code/overview-map/index.html

Also might be worth trolling the esri forums, as this seems like a common thing people will be grousing about.

Our local printing is better.
Might be useful to leave option open to a 3rd party, though we are not that focused on 3rd parties right now.

Instead of using Terraformer and ramming json into a Feature Layer, try to use new class instead for all File / WFS sources

Got decomissioned.

Used for bounding boxes of graphics.

We have a bunch of different config options.

outfields is an optional comma delimited string of field names. If not *, will only include the fields in the list. This impacts the attribute loader. End result affects what is available to display in grid, display in details pane, what's on observables.

fieldMetadata is an array of mappings between field name and alias. Lets author define a custom alias.

The grid config has columns which map to fields. While a bit redundant, I can see the use of having an additional override here if authors want grid to look different / have different column heading.

Possible idea would be to expand fieldMetadata to include an omit flag, replacing the outfields. I.e. you would have to define fields you don't want instead of defining fields you do want.

Another idea is to push the fieldMetadata array into a property of new field metadata object, and add a boolean property for exclusivity. In this case, if true, we only take fields in the field metadata list. Otherwise the list acts as an enhancer (e.g. you only want to override one alias, only need one element. But if exclusive, need every element).