what data? just curios because there are so many ways to do PRs properly.. like for everything, if it's done badly better not do it. does not mean it is inherently bad
depends what you mean by application code.. I'd say if your business logic is exclusively used by a ui feature the best is to keep them together. but you probably want to abstract away things like data access. I found working with a nx monorepo helps reasoning about how to structure your code.
That's why PR should be small. It's much better to have multiple PRs than a single big one.
Totally fair to have gigantic PR full of boilerplate code, but generally you can split the boilerplate and your feature in 2 PRs, where only the feature will get a proper review.
All of this obviously depends on the criticality of the system :p
what data? just curios because there are so many ways to do PRs properly.. like for everything, if it's done badly better not do it. does not mean it is inherently bad