When presenting a collection based interface to end users you'll often want to provide a search field that can be used to filter that data. Conventionally you might accomplish this using the basic pattern of creating an input field above the table or list-view which is bound via it's value to a page variable that is in turn bound to a filter criteria on the Service Data Provider that is driving the collection dataset.
With this pattern, no additional wiring is required for the page developer, however, the end user does need to type a value into the search field and then press tab to update the search variable (this happens as the user leaves the field). As soon as the search variable is changed this then has the side effect of notifying the SDP of the criteria change which in turn automatically triggers the refresh process and fresh query from the Business Object (or other service)
So, what if you want to refine this so that the user does not have to leave the search field i.e. as the user types the table or list-view is continually re-queried?
It turns out that this is pretty simple to do. Rather than binding the search variable to the value property of the <oj-input-text> instead you can bind the same variable to the rawValue property.
Using the following syntax:
Unlike the conventional value property, rawValue updates before the user navigates out of the field. So every keypress will cause an update to the search term and likewise cause the SDP to refresh.
One problem with the use of rawValue is that it does change with every character that the user types. Now that may be OK on mobile because of the slowness of using a virtual keyboard, of the service call is quick to execute, however, in cases of expensive REST calls of fast typing it may be too much! For example, if the user types "Visual" into the search field then this would end up submitting 6 REST calls with the search criteria as follows:
That seems a little wasteful, particularly is the user types quickly and knows the full term they want to search on.
So how to alleviate this? Well there are couple of approaches. First of all you can change the definition of the searchTerm variable to set a Rate Limit as shown here:
The Rate Limit throttles the number of updates that can happen to the variable with the number used representing the number of milliseconds between updates.
In many cases, just playing with the rate limit can tune the number of SDP changes that are triggered and provides just what you need.
If setting rate limit does not quite provide the performance that you need you can add the sample component oj-sample-input-typeahead into your Visual Builder Project. You can find this in the component browser
This component is a drop in replacement for a standard <oj-input-text> except that it internally controls the update of rawValue so that updates only happen when user typing pauses or stops. with this in place, our search for "Visual" would only trigger one SDP update / REST call which is much better.
The <oj-sample-input-typeahead> can be tuned using it's typeaheadWait property (Labeled as Wait Time in the property inspector) which defines how long a pause (in milliseconds) is needed before the change to rawValue is propagated.
Note that components with the oj-sample prefix are indeed samples and are unsupported - so use at your own risk. In a future article I'll show you how you can copy and adapt these example components for yourselves.