Folks, this is why you want to do code reviews inside your editors / IDEs. I like this project, but really what they did is build a read-only version of an IDE from the ground up. You already have one and you know it inside out.

I've found, as the OP did, that the GitHub/Lab/Bucket code review UIs strongly encourage nitpicking over code style and strongly discourage true insightful reviews on a design and architecture level. This happens simply because of the amount of effort your have to do to see and feel the wider impact of a pull request on your codebase. It's like looking at code with blinders on.

So what you want to do is checkout the pull request and use your editor. We made this a habit here at TalkJS and the quality, speed and usefulness of our code reviews skyrocketed.

Actually we take it one step further: we dropped the commenting interface altogether. Our code reviews are commits, with code comments by a particular format:

    // REVIEW(marcin<-egbert): Won't the event listener get re-registered every time this function is called?

My colleague Marcin can find all reviews intended for him by grepping for `REVIEW(marcin`. Git ensures that even across merges and code changes, comments stay put, and once Marcin applies the review comment he removes the comment. He can reply by adding a comment in the same format.

The fact that review comments are right there in the git history also really helps track down complicated problems. Finally, we get the freedom of merging a PR anyway even though some things ought to be better, without losing track of the review comment. Obviously that's a code smell, but sometimes it's better to release first and refactor next day.

But even if you think this is insane and reviews don't belong in the code, I'd like to warmly encourage you to use your editor for reviews.