I am implementing the Search Widget in an application and I am trying to figure out a better way to configure the sources for the widget.
I have a feature service that contains 60+ layers in it and the requirements are to be able to search all of the layers with the Search Widget. Do I really have to manually define every single layer as a LayerSearchSource or is there a better way that I can just give it the feature service url and it can pull all of the layers in as a search source utilizing default values?
Solved! Go to Solution.
Hi @jjgarrett0, thank you for posting your question here. As far as I know, yes, layers have to be configured individually as a LayerSearchSource. Typically, a looping function should suffice. However, can you share a bit more about your use case, and why you want to have 60+ layers as sources in a Search widget?
Hi @jjgarrett0, thank you for posting your question here. As far as I know, yes, layers have to be configured individually as a LayerSearchSource. Typically, a looping function should suffice. However, can you share a bit more about your use case, and why you want to have 60+ layers as sources in a Search widget?
Thanks @Noah-Sager, I had planned on a looping function but just wanted to make sure I wasn't missing something elsewhere in the API. As far as the use case is concerned, my end user(s) have a lot of layers that are loaded into the map (with visibility defaulted to false) and they want to be able to search for any feature in any of those layers.
I think that's what you'd have to do if you utilized the Search Widget, and I don't know about the performance of 60+ layers but it'd probably work at least. If you have only one (or a small number of ) field to search in each layer maybe you could mimic the Search Widget by using the where clause directly on the REST web service, then you could compile the possible features selected in whatever way you wanted from the resulting JSON, as in this REST call:
Ah yea, that could be another route. I'll look into it. Thanks!