feat(hub-common): add viewDefinition and recordCount to fetchContent(… #744
Conversation
…) response affects: @esri/hub-common fetchContent now fetches the definition for client-side layer views and fetches the record count for layers, tables, and proxied CSVs
Codecov Report
@@ Coverage Diff @@
## master #744 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 345 345
Lines 6484 6513 +29
Branches 1176 1188 +12
=========================================
+ Hits 6484 6513 +29
Continue to review full report at Codecov.
|
|
NOTE: the explore view will expect content to have a top-level const getViewFilter = content => content.viewDefinition && `(${content.viewDefinition.definitionExpression})` |
| * @returns layer definition | ||
| * @private | ||
| */ | ||
| export const getItemLayer = ( |
There was a problem hiding this comment.
this fn was just hoisted out of composeContent() below
| const { item, data, layers } = itemAndEnrichments; | ||
| const layer = | ||
| layers && getItemLayer(item, layers, options && options.layerId); | ||
| // TODO: add recordCount here too? |
There was a problem hiding this comment.
I'd prefer to fetch the record count here, where we fetch other enrichments, however, I need a lot of logic that currently only happens in composeContent() getters like isProxied, url, viewDefinition, so I'd have to turn all those getters into fns I could call here. So for now, I just fetch recordCount below in fetchContent() after calling composeContent()
affects: @esri/hub-common resolves [1073](https://devtopia.esri.com/dc/hub/issues/1073)
| layers && getItemLayer(item, layers, options && options.layerId); | ||
| // TODO: add recordCount here too? | ||
| const layerEnrichments = | ||
| layer && isLayerView(layer) && !data |
There was a problem hiding this comment.
I copied the current logic in isLayerView() from composer.js, which only checks layer.isView, but when creating a new layer view to test this I noticed that the item also gets the "View Service" type keyword. We could use that in fetchItemEnrichments() to include "data" in the default list of enrichments to fetch for the item, however, there are layer views that don't have that type keyword (for example the item in #1073), so we'd still have to do this check after fetching the layer.
| ? // NOTE: I'm not sure what conditions causes a layer view | ||
| // to store (at least part of) it's view definition in item data | ||
| // it seems that most do not, but until we have a reliable signal | ||
| // we just fetch the item data for all layer views |
There was a problem hiding this comment.
Furthermore, spot checking a handful of such items from this:
https://qaext.arcgis.com/sharing/rest/search?num=100&start=0&f=json&q=typekeywords%3A%22View%20Service%22
showed that very few had their definition stored in item data, ex:
https://qaext.arcgis.com/sharing/rest/content/items/864c9eaf76ab47ba93d7308bacf1a34f/data?f=json, so most of the time we're fetching the data for nothing.
…) response
affects: @esri/hub-common
fetchContent now fetches the definition for client-side layer views
and fetches the record count for
layers, tables, and proxied CSVs
Instructions for testing:
Closes Issues:
#322 (essentially)
There are additional top-level aliases we could add like
geometryType,capabilities,objectIdField, however, we've decided for now to update the client-code instead to get those fromlayerorserver.npm run c)