You should also consider keeping the place where I say "This is where the magic happens" and wherever I solve the get-rid-of-jquery problem. In general this structure with all the promises and async/awaits is way more straightforward than the telescoping callbacks of old, and the fact your code was missing these new language features was what frustrated and confused me enough to rewrite rather than amend. If it overwrites someone else's changes, they're still labeled a contributor. That's 4 lyfe.

My rate limiting is based on just waiting, accounting for how many queries Spotify's servers are willing to take per time per client ID. I see no good reason to use more than one client ID; it allows you to see the usage of your service in the dev dashboard, which is pretty neat, and you can't very well dynamically generate them to spread load--as far as I know. If one user at a time makes queries, then it will always work. If two or more happen to click the button at the exact same time, then there is no logic to slow the querying down or queue them, so it's possible the server would get overwhelmed and return those concurrent users 429 errors. But this is exceedingly unlikely unless your service gets an enormous number of users. If you truly want to scale, you'll have to consider a better solution. You could hack it and just lower everyone's speed limit, since a collision of n users at once is even more unlikely. But that's gross.

I'm not as attached to my React rework. Again, I didn't and still don't have much experience in it. I'm glad they've updated JSX in the time since, because it seemed like a way less verbose solution than all those React calls.