▲ | Sytten 5 days ago | |
Good PR, but AbortController doesn't really help with stopping the server from processing the request. I have seen so much of this type of search that just continues processing in the backend even if the client has long gone caring. | ||
▲ | Flimm 4 days ago | parent | next [-] | |
I agree. I was expecting the author would implement debouncing or throttling to reduce the number of unnecessary requests, alongside fixing the data race issue. Here's an excellent article on debouncing and on throttling, and the difference between them: https://css-tricks.com/debouncing-throttling-explained-examp... | ||
▲ | hinkley 5 days ago | parent | prev | next [-] | |
There's nobody who really has a library that's set up to feed a sequential task into and have it force a synchronous call to be async with breakpoints to check for early termination. This seems like a problem Sorhus should have a library for, but he does not. I've had the conversation too many times in the last couple months about how setTimeout() does absolutely nothing to fix this problem in NodeJS. Even Java had trouble with this and tried to delete the API that seemed like it should support this problem, due to undefined behavior. | ||
▲ | throwaway0665 5 days ago | parent | prev [-] | |
The sever should cancel the request handler when the client drops. Otherwise you're just opening up to accidental DOS. |