-
-
Notifications
You must be signed in to change notification settings - Fork 457
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate /chatters commands to use Helix api #4088
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
There were too many comments to post at once. Showing the first 25 out of 36. Check the log or trigger a new build to see more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this!
These changes are both pretty heavy, and while they rely on the same underlying functionality (the cursor-pages-fetching thing), it would be a lot easier to review if I could focus on a single functionality rather than two, since most feedback I have would apply to both.
So in short, could you undo the changes either to the /mods command or to the /chatters command (I have no preference) in this PR?
After that's done, I will go ahead and review the code and come with more proper/full feedback
EDIT: btw, feel free to ignore clang-tidy for now, it can come with some weird suggestions :)
@pajlada I totally understand. The only reason I did it this way was because I needed both /mods and /chatters to make the the viewer list be entirely moved to the Helix api. I'll just separate this into /mods and /chatters prs and then once both are merged I'll add a pr that migrates the viewer list. |
@pajlada Code and pr message has been updated. I've got everything in another branch to merge in later. There were a few functions that will be shared for /chatters and /mods so some functions look like they shouldn't be their own thing, but they'll be useful later. |
@pajlada I changed the helper function for helix to be a more generalized version of |
I did this by running the ./tools/clang-format-all.sh script
The number in the parenthesis should link to the PR that implements the change, which is 4088 in this case
This makes the code readable, and if you need to know the exact type your IDE can hint it at you (or you can check the getChatters function definition)
This makes the diff a teeny tiny bit easier to go through
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
Instead of having a shared method to handle the pagination logic, this adds a private `fetchChatters` method that expects the caller to provide all parameters that would be necessary to make the request. This method can then be used from the public-facing `getChatters` method in a recursive manner, while also keeping the error handling code right in that function. With this change, the success result type has been changed to the `HelixChatters` type (the same used in the private method). By doing this, we can provide a consistent & full API for any users of the `getChatters` API and not have to provide a separate API for the `/chatters` function. Other important changes that came with this was also avoiding the use of raw pointers, the previous code had difficult-to-track pointers & memory leaks for every call that was made (chatterList and page). One potential unbenchmarked downside to the refactored implementation is that we make more sets of users instead of adding them straight onto the same one. This is a concession that is worth it in my opinion as it makes the implementation easier to read. If the code was used in some hot spot we can benchmark and reconsider this. Another bonus change added to this feature is that we fetch 1000 chatters per page using the `first` request query parameter, making us use a lot fewer API requests. This means we'll run less functions recursively and worry less about crashing our stack.
@cbclemmer uno reverse card - I committed some stuff to your PR that I'd like you to review/approve. Most commits are small and do very little, they'd be easy to go through and it's easy to understand why. However, I made a big refactor PR for the pagination logic to change the pattern we use. This changes the pattern for paginated requests in this PR and for future paginated requests to need two functions; 1 public one that users (e.g. Let me know if you have any questions! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clang-tidy made some suggestions
@pajlada That all looks good. The reason I wanted to try to make a more general request was because the handling for the status codes and resulting errors were largely copied and pasted so I tried to make a framework to reduce that for the stuff I was writing. It does make a lot more sense to refactor everything later when everything is using a standardized way of handling errors like you commented before. I'm mainly a C# dev and garbage collection is usually an afterthought for me because of that, so thanks for ironing that out. Looks good to me 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not 100% on the fact that we are deprecating the command very early, but /chatters
usage is probably more common among stable users, so we could take another look at this around Feb when the deprecation of all other commands kicks in.
Pull request checklist:
CHANGELOG.md
was updated, if applicableDescription
closes #4019
Features: