Added delay before future request function is executed

[JesusHdez960717]

In the futureRequest of the CustomDropdown.searchRequest, I get data from an API (google places with places_service), but every time the user types a letter, the function is executed and an api call is made, causing an overfetching of the service. The simplest solution (in my opinion) would be to execute the futureRequest after a certain period of time, period of time that restarts if you type another letter.

The implementation is basically adding the Duration: futureRequestDelay property as part of the CustomDropdown.searchRequest constructor, this property is not required and defaults to no delay. Finally, before executing the search function, the time designated in this variable is waited. If another letter is typed during the waiting period, the waiting time is restarted.

[AbdullahChauhan]

Hi @JesusHdez960717, I hope you're doing well.

Thanks for contributing to my package. I've got your point for this PR and that's actually a good point but we need to address two issues first before merging this:

• There shouldn't be any delay when user start searching (type first letter) because I don't think we need any delay enhancement on first call.
• While executing timer (delay duration), it's better to show loading view despite the timer execution so user would know something is happening otherwise currently its like something is not working, stuck etc and then suddenly loading view occurs after delay.

I hope you get these points. Do let me know your thoughts on these!

[JesusHdez960717]

Hello @AbdullahChauhan, It is a pleasure for me to be able to contribute to this package, It's great. Regarding the issues:

• The second you are absolutely right, regardless of whether the futureRequest is running or waiting, the loading should be displayed, so the user knows that he is doing something and not that it broke. I could totally modify it.
• In the first I have my doubts. This is why: Let's assume that we are looking for google places, and the user wants to look for the eiffel tower, so he would type: e - i - f - f - e - l, after he finishes typing, he waits, let's say about 100 ms and really executes the search. If the search is executed instantly with the first 'e', since it is a single letter, the results would not be exact, very little information to search for, and after typing the whole word the search would be executed again, this time with the expected results. The idea with this functionality is not to make unnecessary calls to a resource, it seems to me that searching with the first letter would not meet the objective. The same way, as a developer, we can configure the initial items in case you want to show something from the beginning. This way you load the initial data to show and reuse it every time. Making one first initial call to the api, and one every time the user stops typing

[AbdullahChauhan]

I agree with your explanation and also I think loading view should make the job done for my both points. So if you could just make the loading view available, then we'll merge this. Thanks!

[JesusHdez960717]

Commit done. Now the loading is visible from the first key stroke, even on delay, it's visible.

[AbdullahChauhan]

Hi @JesusHdez960717 I've checked the updated implementation and all looks good now. Appreciated your work 👍 For slight improvement, I just refactored some code to ignore timer execution if futureRequestDelay not provided via constructor API. Can you kindly take a look and test this on your project (if you've any working scenario present)? And do let me know if all works well. Thanks!

[JesusHdez960717]

Perfect refactor, super clean solution. For my, it's perfect. :+1:

[JesusHdez960717]

btw, i have another possible update, but this time will be a breaking change for the package, and I don't know if it's a good idea. It is basically the possibility of working the widget with a list of Objects of type T, instead of with a string. In my particular case, if the search is done on something more complex such as a list of objects, as in the case of google places, the filter has a string as input, but as output a list of Places, and I would like the plugin will work with a List. The solution I used was to map the names of the places to the object, and so I can filter them, but it seems to me a much more generic solution if you could work with generic objects and not just restricted to strings. If you think the idea makes some sense we can create an issue to discuss it in more detail, and if something serious is reached, you could implement it.

[AbdullahChauhan]

btw, i have another possible update, but this time will be a breaking change for the package, and I don't know if it's a good idea. It is basically the possibility of working the widget with a list of Objects of type T, instead of with a string. In my particular case, if the search is done on something more complex such as a list of objects, as in the case of google places, the filter has a string as input, but as output a list of Places, and I would like the plugin will work with a List. The solution I used was to map the names of the places to the object, and so I can filter them, but it seems to me a much more generic solution if you could work with generic objects and not just restricted to strings. If you think the idea makes some sense we can create an issue to discuss it in more detail, and if something serious is reached, you could implement it.

Yup, you are right about this and this would have been a big plus for this package. Actually, this has been in my plans for longer time but couldn't able to get time for this. Hopefully, I'll implement this in one of next release!

[JesusHdez960717]

I will take a look in this days about the List change, and if it's possible, I will try to do an initial version. Maybe between the two of as could make some progress. In any case, I'm happy to be able to collaborate with this package and you @AbdullahChauhan. Thanks for all the attention. Hope this PR will be merged soon. Best regards

[AbdullahChauhan]

Yeah, that would be good if you initiate this. I highly appreciate your interest and work for this package. Will merge this soon!