How to assist consumers in formating query response values, i.e. based on popupInfo?

[tomwayson]

This recently came up in https://github.com/Esri/arcgis-rest-js/pull/386#discussion_r232855938, if we're processing fields to decode coded value domains should we also provide a way for consumers to format date and numeric fields?

There has also been interest in potentially using the format info from fieldInfo objects in a layer's popupInfo to format attribute data.

Seems like if we wanted to take this on our choices are:

• use the built-in toLocaleString() fns (now we need to know the locale and deal w/ potential browser/node idiosyncrasies)
• let consumers provide a callback where they can use whatever formatting library they have (how much are we even helping at that point?)
• ~take on another library as a dependency~

The latter isn't really even an option considering that even the smallest date formatting library out there, dateformat, is ~1.5x the size of the entire @esri/arcgis-rest-feature-service package. The depressingly popular moment.js is about 64x as large!!!

Maybe one thing we could do as a start that could be useful is to provide a fn that translates the ArcGIS date format types to patterns like MM/dd/yyyy that can could then be used w/ popular date libraries like moment. See these examples. That would depend on the date libraries using the same or at least very similar patterns.

[jgravois]

i played around a little today and noticed that in the JSAPI, when a layer is instantiated from a portal item, its popupInfo doesn't impact what is returned by 'queryFeatures()'.

instead, the attributes associated with a particular feature are massaged after the fact (just in time to display a popup).

because of this, i guess it makes sense to follow the pattern we established in #386

queryFeatures(/* */)
  .then(queryResponse => {
    formatValues({
      queryResponse,
      // use the item id to fetch fieldInfos if they aren't provided directly
      fieldInfos: itemId as string | fieldInfo[]
    })
      .then(formattedResponse)
  })

where to put the utility function though? items doesn't make a whole lot of sense, but given what we'll need to call internally, neither does feature-service.

either way, more information about the proposed use case would be helpful.