My understanding is that trunk based development should rely on direct commits to master or short-lived feature branches that are merged with master. Incomplete work can be placed inside functions that are then toggled off with feature flags.
For short-lived feature code review: developers can work together in person to review work before/shortly after it is committed to the master branch, or they can create pull requests from their short-lived feature branch to master and review before merge.
I'm working on a project where code review would be beneficial and currently a lot of the team's (3-4 juniors and 1 Sr.) features are long-lived. It seems like the code review approach would be to use feature flags to hide incomplete work, and then have developers break a long-lived feature out into discrete chunks of work that live on short-lived feature branches. These can be reviewed via pull request as the feature progresses to completion.
The reason I'm considering recommending this flavor of trunk-based development over GitFlow is because the Git knowledge there is thin so fear of merge conflicts looms large for the team. They also currently practice trunk-based development except that they don't have automated testing, use branches, perform code review, and don't use feature flags so deployment get delayed because of unfinished work sitting on master.