Unless I'm misunderstanding, you are building a custom widget.
There are two UI interfaces that act as thee primary entry points for a custom widget.
The first is the obvious one: widget.tsx (for me this is in a folder under the widget like src/runtime/widget.tsx)
This is displayed in the UI in the Dashboard editor, and in the location when the widget is active or present on screen when previewed or run.
-> IN your above example, you can in theory have a group of data sources loaded in a dropdown and select them. That does not always make sense for the users, because they may not even know the data source names.
The second is the settings section. The settings section becomes active in the right pane of the Exb dashboard editor when you make your widget active in the canvas. Whether its in a panel, or a button clicked from a widget controller, if you have a settings.tsx file (usually under src/setting/setting.tsx file) You might set up a setting to be selected. It could be anything, a map, a data source, controls for dynamic text, or sizing that you want to use on your page (the sky, provided it passes sanitization for XSS is the limit)
here is an example widget for toggling layers that shows a settings.tsx for a map for example
https://github.com/Esri/arcgis-experience-builder-sdk-resources/blob/master/widgets/view-layers-togg...
The key difference between widget and setting files is that setting view is set at Design time in the edit dashboard, its not intended to be changeable by a user, but setup when the app or widget is deployed. Meaning you can reuse a custom widget in other dashboards, provided you configure it with a similar setting or data source. Because of that, your users won't know what's connecting to, but if there are other controls (I think you might be able to get map layer visibility for example) You could in theory use that to update the query and return a different set of data.)
On the second part. Feature Layer Data Source, yeah this took me a while to get:
So for example. one thing you can do is cast a DataSource as a FeatureLayerDataSource and if its an actual valid DataSource it can act as one. I created this method to help me with checking if a given datasource index was loaded and if not wait and keep checking.
waitForDataSource = (layerIndex) => {
return new Promise((resolve) => {
const checkDataSource = () => {
const dataSource = this.props.useDataSources[layerIndex]
if (dataSource) {
const dataSourceId = dataSource.dataSourceId
const dsParcels = DataSourceManager.getInstance().getDataSource(dataSourceId) as FeatureLayerDataSource
if (dsParcels) {
resolve(dsParcels)
} else {
setTimeout(checkDataSource, 100) // Retry after 100ms
}
} else {
setTimeout(checkDataSource, 100) // Retry after 100ms
}
}
checkDataSource()
})
}
However, there are a couple of things to remember. 1. if the FeatureService you are doing is a pure RestService you may not be able to run queries directly on it with query, so I often grab the url from the dataSource and if the url exists, use that to do a restful query from experience builder to grab the feature(s) and their geometry/attributes and then do something with them:
This example is a little more plain, but might illustrate it another way. I like to build a fall back in for calling the RestURL in case a FeatureService gets deployed without being part of a map as a FeatureLayer
const getObjectId = async(objectId, layerIndex) => {
layerIndex = dataSourceIndexes.SecondDataSource;
const dsManager = DataSourceManager.getInstance();
const useDataSource = useDataSources[layerIndex];
if (!useDataSource) {
throw new Error(`UseDataSource with index ${layerIndex} not found.`);
}
const dataSource = dsManager.getDataSource(useDataSource.dataSourceId) as FeatureLayerDataSource;
if (!dataSource) {
throw new Error(`DataSource with id ${useDataSource.dataSourceId} not found.`);
}
const dsFeatureLayer = DataSourceManager.getInstance().getDataSource(dataSourceId) as FeatureLayerDataSource;
if (!dsFeatureLayer) {
throw new Error('FeatureLayerDataSource not found');
}
const whereClause = `ObjectId = '${objectId}'`;
const outFields = '[*]';
// If the feature service has layer defined at this point, then we query it this way
if (dsFeatureLayer.layer) {
const query = dsFeatureLayer.layer.createQuery();
query.where = whereClause;
query.outFields = outFields;
query.returnGeometry = false;
const results = await dsFeatureLayer.layer.queryFeatures(query);
if (results.features.length > 0) {
return results.features[0].attributes as MyObject; // Where MyObject is a type or interface we defined somewhere.;
}
} else if (dsFeatureLayer.url) {
// Otherwise, we check if the URl is set, and cerate a new query formated for a REST Call, and add the token on the end
// (which can be gotten at the widget's top from this.props.token and passed into the method/component
const url = `${dsFeatureLayer.url}/query`;
const bodyParams = {
f: 'json',
where: whereClause,
outFields: '[*]',
returnGeometry: 'false',
token: token
};
// Format the URL Search Parametrs for the request
const body = new URLSearchParams();
for (const key in bodyParams) {
body.append(key, bodyParams[key]);
}
// Now this looks like a Post instead of a GET, I had expected this to be a GET Method.
// Note this is the async/await method for calling into an asynchronous endpoint (the other is .then/.catch read up on JavaScript Promises to know more)
const response = await fetch(url, {
method: 'POST',
headers: {
'Content-Type': 'application/x-www-form-urlencoded'
},
body: body.toString()
});
// Once the response returns an OK we can then let the content be processed as JSON
if (response.ok) {
const result = await response.json();
if (result.features.length > 0) {
return result.features[0].attributes as MyObject; // Where MyObject is a type or interface we defined somewhere.
}
} else {
throw new Error(`Error querying features via REST API: ${response.statusText}`);
}
} else {
throw new Error('FeatureLayerDataSource.layer or URL not found');
}
throw new Error('MyObject not found');
};
EDIT:
Just realized you were hard coding the URL, you can certainly do that as well, it means every time you change host or the path of the service moves you'd have to update the widget in the code, but you can do that in theory.
I realize my examples aren't looking like Sql as much too, so there are some subtle differences. but if the DataSourceComponent is tied to a source that helps manage a query, updating the state should trigger it to requery I think.
