Closed matteolel closed 4 years ago
I would prefer not to package the entire list of all historical players with the library, but rather have users request that list at runtime if they need it. I don't think the rate of usage of those players justifies the bloat. I'd be happy to accept a PR for a historical players method on the library
Ok, it makes sense. Do you think that parsing https://stats.nba.com/js/data/ptsd/stats_ptsd.js is the right approach for that new method?
Huh, I didn't look closely at what that endpoint outputs. It'd be ideal if we could find a JSON endpoint that outputs that data – otherwise we have to slice the string response so we only have the JSON data and parse that. I'll see if I can turn up something.
Any chance you know the URL of the page on www.nba.com you were on when you found that request?
I looked for an JSON endpoint, but I didn't find anything at a first sight.
Instead, I found that this file is download from here https://stats.nba.com/ and I think it was used for the hint during the search. I'm guessing that because if you have a look at the network requests, nothing happens while you're typing in the search bar at the top-right of the page. So, I'm supposing they eval that file at the beginning, instead of using AJAX requests.
I didn't find anything useful in the API endpoints list, so I'm going to close it and opening a new PR.
For my understanding, we have 2 arrays of players:
In order to have an unique array with both information, I'm going to merge them.