Request
Add sqlExpression as an optional parameter to the featureSetBy Aracde functions to help the performance of the form. Making it optional makes it backwards compatible as well.
New Parameter
- sqlExpression (Optional) Text - The SQL92 expression used to filter features in the layer. This expression can substitute an Arcade variable using the character.
Discussion
Pretty standard workflow is to get a feature set (currently must get all records). Then use the Filter() function to drill down to a subset of features. Then loop through the features to get access to a particular feature.
It is pretty easy to get the form into an odd state, where the form behaves unpredictably or becomes altogether unresponsive, even with the current options to limit the number of fields and not returning geometry.
When using these functions in a popup the calls happen once, but in a form each call happens every time the form state changes... that might a 100+ times per edit session. If you have 10 fields fetching data that is a 1000+ calls for data. The number of calls might be necessary, but does the client need all 100,000 records every time it makes a call just to get down to 1 record?
There may be something else at play here as I imagine leaving this out was a conscious decision in the first place. Is there are reason we wouldn't want the initial filter to be performed server side so that the client just had a subset of data to work with from the get go?
I have a more advanced workflow to reduce the shear number of calls for data in the event that multiple fields are fetching data from the same source & feature. In the example above, say all 10 fields need different data from the same feature, then I have an 11th field that fetches the data and returns all the fields needed by the others as a JSONified string. Then the 10 other fields just parse the JSON for what it needs rather than making their own calls. This way, per form state change, only 1 call external dataset is called rather than 10. While this helps tremendously, my forms are complicated enough and the external datasets are large enough the the performance hit is noticeable in both AGOL & Enterprise.
Note:
There is a similar request in ArcGIS Online ideas that was submitted early this year revolving around popups. This was before form calculations in ArcGIS Field maps really got going. I want to give it a bump and provide some context within form calculations. You can find it here.
