Entity reference widget only works if you type slowly

Hi Dieter,

I've been testing the issue, and everything works fine on my end. The browser console shows the AbortError when a request is aborted (e.g., when the input value doesn't match any suggestion and it has been typed quickly), but this error does not affect the behavior of the Tagify element.

I will test this more carefully, but it should not be a big issue.

This one might also have been fixed in ✨ Add support for custom form-element supporting entity_reference Needs review . I applied that one as patch to my project and I'm running it on production now, will report back if this happens again.

Just tested and it's definitely still happening. Not all the time though, the problem is that it sometimes doesn't show results even though it should. Not sure if it matters, but I should probably note that I'm using Firefox.

On Firefox with the Gin theme, the AbortError occurs every time I type at a normal speed—not too fast, not too slow.

On Chrome is more difficult to reproduce it, but it is also reproducible using Claro as default theme.

In both cases, the suggestion dropdown correctly shows all relevant content without any issues.

See evidences:

Claro - Chrome

Gin - Firefox

I've been checking between versions and 1.2.11 doesn't have the "bug", so the "bug" was definitely introduced here: https://www.drupal.org/project/tagify/releases/1.2.12 → , but I need some time to debug it in depth.

I've found the problem, seems like this is related with the wait time in the Drupal.debounce.

@param {number} wait
  The time period within which the callback function should only be
  invoked once. For example if the wait period is 250ms, then the callback
  will only be called at most 4 times per second.

We removed the wait parameter from the input in 1.2.12

I tested all commits you did separately. A 250 wait time works, but honestly 50 feels a lot snappier/more fluent to me. Why did you change to 250?

Hi Dieter,

Thanks to take a look on this.

If we set the wait time to 50ms in the debounce function, it is making the tests fail.

See:

@param {number} wait
  The time period within which the callback function should only be
  invoked once. For example if the wait period is 250ms, then the callback
  will only be called at most 4 times per second.

I need to find some time to figure out how we can fix this in the best way.

Okay, I noticed 50 works great on my local environment, but it doesn't work on production. 250 works on both. This is probably a performance thing, depending on how long page loads take. In that case 250 is probably a safer bet - or maybe something in between. I'll try out some different values on production.

150 seems to work on both as well. I'll go for that value on my website right now, but maybe it would be best to make this configurable (or at least alterable through some hook) in order to improve responsiveness on faster sites.

Never mind, 150 still fails sometimes. 250 seems to be a good default.

It still fails randomly, depending on how fast you type, and the Error fetching data: DOMException: The operation was aborted errors still appear in the console. I feel like there's still something else going wrong, other than the configured timeout.

I noticed that when you're typing fast in the autocomplete field, for every keystroke, a new request is sent to the server. Previous requests are aborted by the client on the next keystroke, but the request is still sent to the server, causing unnecessary load. Could you maybe implement some sort of debounce function to make sure that doesn't happen? Apart from that, everything seems to work alright. I'm updating the patches on a couple production projects I'm using regularly, so I'll report back if I encounter any strange behaviour in the next weeks.

Thanks Dieter for the quick feedback!

The main issue was the 'no matching item' message which was appearing immediately after typing, even when a match existed. This was caused by the lack of debounce on the dropdownItemNoMatch function, which resulted in an early feedback. To fix this, I've wrapped dropdownItemNoMatch in a debounce, ensuring smoother performance and preventing the message from displaying unnecessarily.

This seems to work very well! For a long time, the Tagify widget was a bit buggy. The changes here seemed to have fixed that. I'll let you know if I encounter anymore weirdness, but during my testing in the past days everything seemed okay.

Thanks for the review Dieter!

It will be included in 1.2.30 release.