RequestInterceptor looks like just the thing I need.
Firstly, the JS API queries the feature layer to get metadata (spatial reference, extents, etc.). I listen for that response, checking for presence of the "supportedQueryFormats" property in the response. The layer I'm querying supports PBF format, which isn't easy to manipulate, so I override the "supportedQueryFormats" property in the response to only list "JSON", so subsequent feature queries request JSON responses. Like this:
const myFeatureUrl = 'https://....';
esriConfig.request.interceptors.push({
after: (response) => {
if (response.url.indexOf(myFeatureUrl) !== -1) {
if (response.data.supportedQueryFormats) {
// Force feature querying to use JSON instead of PBF,
// to make it easier to intercept and manipulate.
response.data.supportedQueryFormats = 'JSON';
}
}
}
});
Subsequent responses, despite being JSON, come in an ArrayBuffer, but I can at least convert that, manipulate the content, then convert it back to an ArrayBuffer so later parts of the ArcGIS JS query pipeline are happy. Like this:
// ab2str and str2ab are external functions for ArrayBuffer / string conversion.
const myFeatureUrl = 'https://....';
const otherData = []; // Populated otherwise...
esriConfig.request.interceptors.push({
after: (response) => {
if (response.url.indexOf(myFeatureUrl) !== -1) {
if (response.data instanceof ArrayBuffer) {
// Convert the response into a JS object, add extra attributes to
// the features, then convert back to ArrayBuffer for the sake
// of later parts in the ArcGIS JS API pipeline.
let responseData = JSON.parse(ab2str(response.data));
if (responseData.features) {
for (let feature of responseData.features) {
let keyValue = feature.attributes.keyProperty;
if (keyValue) {
let data = otherData.filter(d => d.keyProperty === keyValue)[0];
if (data) {
feature.attributes.extraAttribute1 = data.extraAttribute1;
feature.attributes.extraAttribute2 = data.extraAttribute2;
}
}
}
response.data = str2ab(JSON.stringify(responseData));
}
}
}
}
});
The JSAPI isn't open-source, so we don't provide the unminified code anywhere.
Combined with limited documentation on the subject, this does unfortunately make extensibility difficult.
We only have custom layer extensibility for Tiled layers, not FeatureLayers.
Thanks for clarifying. It's not easy to discover this otherwise. I've found documentation for Tiled layer extensibility, there's a good example of the "blend layer" approach. But a lack of similar documentation for Feature layers doesn't make it obvious that it's not intended to be extended from. I imagine if I could dig deep enough, and reverse engineer the minified code, it would be possible, but it feels like swimming upstream.
From the outset, I hoped, and kind of expected that for feature rendering I'd find a function callback where I'd receive the graphic / feature to be rendered as input, and be able to provide the rendering properties / symbol on that basis. Arcade expressions, visual variables, etc. are OK, but if I've got a use case they don't fit, it looks like I'd be left with few (no?) alternatives. I guess this is because the arcade expressions approach is a means to provide a common abstraction across all platforms? But it would be great to still have the option to get one step deeper and have more control over the rendering. What's the preferred avenue for providing such feedback to the product team?
