Strategy for FilteringSelect based on street names

[SteveCole]

I kinda have an idea about how to do this but I wanted to throw it out there in case there's a method I haven't thought of.

In my app, I want to have a FilteringSelect listbox so that users can start typing the name of a road within my county. The dataset of roads has close to 40,000 features so that's obviously way too many records for the FilteringSelect. If I run a frequency based on the street name attribute field, I'm down to 5,000+ unique values.

My thoughts were to create the frequency table on street names, publish that in a service along with setting the returnMaxRecords to just above the maximum number of records in the table, and then setting the FilteringSelect data store to all the records when the app loads. Is that the best way to do this?

The only other thing I can think of is tapping into the keypress event of the FilteringSelect box so that everytime a key is pressed, the street feature service is queried for "like" records (i.e. "NAME like 'Main*'") and update the data store for the FilteringSelect. Something tells me that this won't be that responsive from a user perspective, though.

Steve

[thejuskambi]

I feel 5000+ is still a big number. See you you segregate the prefix suffix and street type, and see if the number reduces.

Otherwise, keydown is not as bad, if you have a minimum chars before you start pinging to the server. The lesser the result set the better the response time.

[SteveCole]

As it turns out, 5,000 records isn't that bad. The app does seems to load a little slower (not huge but enough to notice) but the FilteringSelect works pretty responsive. I do like your suggestion of a minimum number of characters before querying, though. Might keep that in the back pocket if this other method doesn't end up working out.

[ChrisSergent]

I take it your using the new search box. Wouldn't autocomplete help with the responsiveness?

[SteveCole]

Chris Sergent​ no- I'm not using it. I'm just using the standard dojo FilteringSelect. As far as I can tell, autocomplete for it is responsive even with 5,000 records under the hood. As I mentioned previously, any "lag" occurs during initial load when the data store is getting created.

[ChrisSergent]

I know it won't speed it up, but have you considered displaying a different cursor while it waits or an icon to the right of the search that might display while populating. That won't solve speed issue but your user will know that the app is still working.

[SteveCole]

I don't think the lag is significant enough to go through that. It noticeable to me because I'm the developer and I know what it was like before I increased the number of records. I don't think a new user will notice anything.

I opened the app in a different browser than what I've been steadily developing with and the app loaded in 3.31 seconds. The QueryTask with the 5k records took 571ms. I'm happy with performance so far.

[JoshHevenor]

For some situations my team has created .net services that can feed JsonRest stores. If you're running SDE and can get at your database directly you can get great performance this way.  

dojo/store/JsonRest — The Dojo Toolkit - Reference Guide

I've also created a custom FeatureLayerStore that wraps dojo's api/store around a feature layer. Our current database doesn't support pagination and the performance isn't great this way. When we upgrade our DB I expect to see suitable performance this way.

But, it looks like the pre-load method is working for you fine. Remember to set returnGeometry to false on your query, and an index on your streetname field won't hurt.