Im curious OP, what was the specific callsite (not overall category) that made you write this library? What did the code look like before/after you used this library?
And in that callsite, what were you doing with the resolved value?
Very nice. I've become addicted to using the `openapi-typescript` libraries to ingest type definitions and then `openapi-fetch` for an automatically-typed client, your debounce library slots over it while preserving all the typing and IntelliSense information.
I don't like sloppy readmes either, but this one doesn't seem that. It's verbose but it's just documenting the API. There's no obvious LLMisms like "Why you should use this (the honest part)" or "Debouncing (the part that matters)".
Im curious OP, what was the specific callsite (not overall category) that made you write this library? What did the code look like before/after you used this library?
And in that callsite, what were you doing with the resolved value?
[dead]
Very nice. I've become addicted to using the `openapi-typescript` libraries to ingest type definitions and then `openapi-fetch` for an automatically-typed client, your debounce library slots over it while preserving all the typing and IntelliSense information.
Anyone else notice that debounce is a popular FE interview question?
It's one of those things that shows you know the basics of frontend, but is still easy to get wrong.
cool but maybe rename it to something more catchy and memorable...ok i will propose new name: dab.js
The README is slop, so I truly don't care.
I don't like sloppy readmes either, but this one doesn't seem that. It's verbose but it's just documenting the API. There's no obvious LLMisms like "Why you should use this (the honest part)" or "Debouncing (the part that matters)".
Most people can't tell the difference. Entertain the possibility that you might be one of them.
> Don't be curmudgeonly. Thoughtful criticism is fine, but please don't be rigidly or generically negative.