dijit.form.TextBox delayed onChange

[Marcin Gołębski]

It will be nice to have callback function which is invocked some delay after last input changed (like in dijit.form.FilteringSelect?).

The patch attached introduces such functionality.

[Adam Peller]

Why not just connect a function with setTimeout to the onChange event?

[Marcin Gołębski]

For simplicity reasons. You have to mantain timer object, check if it is already fired, or not. My solution just do it for you.

[bill]

I just don't understand why you want this? onChange only fires after the input blurs, right?

[Marcin Gołębski]

Replying to bill:

I just don't understand why you want this? onChange only fires after the input blurs, right?

You right, onChange fires when:

• input blurs or
• on every character when intermediateChanges==true

but, when you wan to use TextBox? as a entry box for filtering for instance DataGrid? you want to do filter precedure not on every character or after user exit TextBox?, but after user finishes typing.

[Adam Peller]

we can't mark this future unless we understand the need for this enhancement. please reopen if necessary.

[Adam Peller]

ok, sorry, I missed the previous comment. I still feel that this doesn't belong in the base class functionality. It would be much better if we had a generic facility for dealing with events and reducing them to fire on an interval.

[bill]

That's what ​http://dojocampus.org/content/2009/09/28/rate-limiting-with-javascript/ is about, BTW.

I do see the reason for the request but it probably doesn't belong in the base code of dijit. If we get more requests for it maybe we can reconsider.

As for the example of filtering data in the grid (basically doing for Grid what ComboBox does natively), it seems like you would want a better solution than just a delayed onChange. For example, if the user types "ca" and then pauses (and thus you start a query to filter the Grid to entries matching "ca"), but then before the query returns the user starts typing more letters, then wouldn't you want to cancel the in-flight query?

[Marcin Gołębski]

Replying to peller:

I still feel that this doesn't belong in the base class functionality.

Ok, I don't want to insist. I haven't feel the spirit of digit yet :)

[Adam Peller]

Replying to mgolebsk:

Ok, I don't want to insist. I haven't feel the spirit of digit yet :)

The spirit is to keep built-in options limited and code small, while making it possible to do things by extension. Take a look at Pete's article and see if it provides a more generic but still elegant approach. If not, we can revisit this.