f=geojson not returning geojson for queryFeatures

[apfister]

I saw this 79bc776, but i'm not able to return geojson using the example in the docs:

require("isomorphic-fetch");
require("isomorphic-form-data");

const {queryFeatures} = require('@esri/arcgis-rest-feature-layer');

queryFeatures({
  url: "http://sampleserver6.arcgisonline.com/arcgis/rest/services/Census/MapServer/3",
  where: "STATE_NAME = 'Alaska'",
  f: 'geojson',
}).then(result => {
    // result is still in arcgis json
    console.log(result);
});

[apfister]

if i add f to the queryOptions list here, https://github.com/Esri/arcgis-rest-js/blob/master/packages/arcgis-rest-feature-layer/src/query.ts#L189, geojson is returned. is this something that's an easy fix?

[COV-GIS]

f is a request option https://esri.github.io/arcgis-rest-js/api/request/IParams/ not a queryFeatures option.

queryFeatures({
  url: "http://sampleserver6.arcgisonline.com/arcgis/rest/services/Census/MapServer/3",
  where: "STATE_NAME = 'Alaska'",
  params: {
    f: 'geojson'
  }
})

[apfister]

@COV-GIS hmm, thanks and I can see that does work. It is a bit confusing though because the query parameters for a feature service aren't usually nested like this when making a REST call to the service. I assumed that params like url where and f would be on the same "level", if that makes sense.

maybe this can be adjusted or at the least, documented a bit more?

[COV-GIS]

It's a pretty rare case that f isn't json. So it's baked in as the only real default as well as f being the only required param for all REST calls. The helper methods like queryFeatures simply expose common params for that particular REST call as top level params. With the exception of url, they get mixed into params for the request itself. params allows you to add any additional params which are not exposed or custom ones. You could add where to params and it will work just fine. As a stylistic choice and because params often times gets constructed thru several functions, I put all options in params and simply use the helper methods to construct all the proper endpoint urls beyond the feature service url.

const params = {
  outFields: '*',
  time: `${start}, ${end}`,
  where: resSite ? `resSite = '${resSite}' AND resDeleted <> 1` : 'resDeleted <> 1',
  token
};
queryFeatures({ url, httpMethod, params })

All that being said, the maintainers are quite open to API and docs PRs.

[jgravois]

the fix for this should be as easy as adding f to IQueryFeaturesOptions and the array of whitelisted custom params here.

and @COV-GIS is right. PRs are always welcome. 😄

[apfister]

i can do this!

[dkuida]

@jgravois a related question. In the whitelisted params "geometry" and "spatialRel" are absent. They do appear in the TS definition. Is there a reason for that? Or simply not enough time to implement the Spatial query functionality. If it is the case I would gladly create a PR

[jgravois]

@dkuida that's just another oversight.

a PR would be welcome. to avoid the hassle of merge conflicts, I'd recommend waiting until #589 lands.

[tomwayson]

@dkuida those were added in #592 and will be released soon along w/ #589