Some real-time filtering of "huge" lists can be done client-side for very fast UI reaction times, but not if the rendered DOM elements are all created and hidden. The solution of using 'listviewbeforefilter' works great (thank you!).
Proposed: Enough of the use cases could be abstracted into a pre-packaged part of the solution. I implemented this for a project, and after working with it for a while, believe that it would make a good standard part of JQM and useful to others.
Features:
- Array of data (required. Only required attribute: t[itle])
- How many letters need to be typed before showing any of the list (optional, default: 2)
- Max rows to be matched and shown (optional, default: 10)
- Ordering attribute (optional, default: the only required "t" attribute for alphabetical ascending, but easily set to something else like "c[ount] descending")
- Rendering callback (optional, default: <li>{{t}}</li>)
- Filtering callback (optional, default: word-lowercase-prefix-match, so "ho to" matches "Hot Trending Topics")
The solution would take care of the necessary "create, refresh, updateLayout" that is needed if the list elements contain buttons or other elements that need JQM enhancement.