@mhmcdonald Same issue here.

There's is a 'racing' condition when typing:

Typing triggers a server call.
Depending on how fast/slow it responds, you will experience the issue.

This does not occur when typing fast since the debouncing takes care of it.
If typing 'slow', then the server has the time to respond, and overwrite the current input value.

Not that if you have a slow connection, it would make the matter even worse - as in you will have to type fast, or very slow.

But if you hit the 'wrong' speed when typing, it gets out of hand 😃

Notice on the video the server calls on the right. When they return, they override the input value.

Note: I'm typing 'hope' and then 'keyword'

I believe the way to work around that would be to decouple the searching from the rendering.

I'm happy to open a PR for that, I found the issue, just give me a day or two 👍

Made a bit of progress here - not as much as expected.
The library is heavily relying on inheritance and events, it took me a while to find my way around 😄

So, it turns out it is an issue related to the way we debounce the user input - there might be no racing conditions with the server as I initially thought.

As a quick fix, you can disable the debouncing until I fix this properly:
src > view > plugin > search > line 102 > comment out : onInput = debounce(onInput, this.props.debounceTimeout);

This will get rid of the bug.
However, depending on your use case you might overload the server as it disables any debouncing on the user input.

I'll try to keep you updated soon once I've done more digging 🔧 👍

Thanks for the update @aloysb - I really appreciate you digging into this

There you go! 🍻 @mhmcdonald

Feel free to pull on that branch until the PR is merged.

It seems that sometimes the answer is just KISS Keep it simple, stupid.
Look at how small the code changes I've made are 😄

There is no need to have the search input controlled (at least, at this stage) - and it does create a racing condition.

Rather than having the current input and the current search stored separately, I've simply turned the input into a plain ol' uncontrolled component since it doesn't HAVE to be controlled and ... tada! 🎉 no more racing condition 👍

Amazing, thank you @aloysb! You rock! I will be watching the PR.

Hey @mhmcdonald ,

Just to let you know that we'll aim to get this reviewed soon, maybe next week 👍

thanks again for the update @aloysb!

There you go! 🍻 @mhmcdonald

Feel free to pull on that branch until the PR is merged.

It seems that sometimes the answer is just KISS Keep it simple, stupid. Look at how small the code changes I've made are 😄

There is no need to have the search input controlled (at least, at this stage) - and it does create a racing condition.

Rather than having the current input and the current search stored separately, I've simply turned the input into a plain ol' uncontrolled component since it doesn't HAVE to be controlled and ... tada! 🎉 no more racing condition 👍

Could you please elaborate how to turn the input into a plain of uncontrolled component?

But if you type at the wrong speed, you create this racing condition.

Increasing the wrong speed is quick fix from the config side meanwhile.
debounceTimeout:1000,
Works for me.

But if you type at the wrong speed, you create this racing condition.

Increasing the wrong speed is quick fix from the config side meanwhile. debounceTimeout:1000, Works for me.

Where did you set the value of debounceTimeout:1000 ?

Where did you set the value of debounceTimeout:1000 ?

In the search block
search: { debounceTimeout:1000, server: { url: (prev, keyword) =>${prev}?search=${keyword} } },

It's in the docs:
gridjs.io/docs/config/search

Where did you set the value of debounceTimeout:1000 ?

In the search block search: { debounceTimeout:1000, server: { url: (prev, keyword) =>prev?search={keyword} } },

It's in the docs: gridjs.io/docs/config/search

Just a matter for RTFM, thank you for that.

#1267 can potentially fix this issue. Can someone run some tests on that branch please?

#1267 can potentially fix this issue. Can someone run some tests on that branch please?

The issue still persists.

@abitbetterthanyesterday i feel like your solution is optimal but there's a small catch which is not handled and that's why we have to keep the search keyword in the state. Like if you want to pass an initial value to the grid than your solution would not honor that and behave inappropriately. I have a small fix for that which I am thinking to create a PR. It's more like persist the input keyword in the state using useState and in addition to that call the debounce method of the text input as is.

@afshinm let me know your thoughts on the solution.

I'm interested in this, I'll increase the debounce timeout for now but a better solution is appreciated, thanks to everyone involved!

This happens for client side as well with a reasonable amount of data (~800 total rows, 100 rows/page, 10+ cols)

ETA: Not sure if the client side problem is related to the same root cause as the server side, but it seems to be mostly mitigated by removing the debounce altogether:

search={{
  debounceTimeout: 0,
}}

I think the "next event cycle" is still causing a bit of an issue with removing text if you type really fast, but its mostly fine now. Ideally we can no-op the debounce if the entire grid is loaded in the client

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.