Good point! When I was new to the Zulip codebase I thought the same but after a while, my views changed. Its a very long model (and file) but very linear and organized, so it doesn't have that usual set of problems for which we have the common wisdom of not having long classes or methods.
Basically, for this you have to ask yourself why you want to split it and what would you split it to. If ultimately what we'll get is something like UserProfileA, UserProfileB, UserProfileC, then that's arguably worse than one long UserProfile.
Basically, for this you have to ask yourself why you want to split it and what would you split it to. If ultimately what we'll get is something like UserProfileA, UserProfileB, UserProfileC, then that's arguably worse than one long UserProfile.