I’m making a wrapper for pronounDB, and one of its things where you can have pronouns displayed is in twitch. Issue is, it requires a user ID, not a username.
My first thought was to go see how the official extension did it and was disappointed to see it reads react props.
No matter, I thought to myself. I’ll just scrape the HTML. And then the universe hit me in the face with dynamically loading content.
Since that was out of the question, I decided to try find some unofficial API that did it for me. I found a site that did, and noticed it mentioned the twitch helix api. Upon a little digging, I came across this post that mentions the endpoint in question. But oh, the misery, it needs a Client Id.
Now, i did read the following on the docs:
Do not share client IDs among applications; each application must have its own client ID. Sharing client IDs among applications may result in the suspension of your application’s access to the Twitch API.
To what extent does this apply for libraries, like in the case for me? How does it apply for unit tests?
Well the other thing you need to access the Twitch API is a logged in user to provide an access token, or using a ClientID/Secret to generate an access token.
So you need to solve that issue.
A “wrapper” doesn’t take a clientID, the user using the wrapper supplies a clientID to work with right?
So you don’t need a clientID, the user using your wrapper does.
Since this is a browser extension it runs inside the page so it can access other params that exist on the page. So naturally it’s react-ing
A library won’t use a ClientID, the user using the library supplies that
Sure for testing you’ll need to use a clientID but only you’ll be using that as users of your library will provide their own credentials. You won’t distribute the library containing your clientID.
Well the other thing you need to access the Twitch API is a logged in user to provide an access token, or using a ClientID/Secret to generate an access token.
According to the other post I mentioned, the one endpoint I actually need only needs a client ID, unless that info is out of date?
A “wrapper” doesn’t take a clientID, the user using the wrapper supplies a clientID to work with right?
So you don’t need a clientID, the user using your wrapper does.
that’s true
Sure for testing you’ll need to use a clientID but only you’ll be using that as users of your library will provide their own credentials. You won’t distribute the library containing your clientID.