Yes! First, you need to get the DOM-level behaviour right (dragging, resizing, cursor focus). That could mean you may use or build primitives like with interact.js, CodeMirror/Monaco (realistically just use, not build), Fancytree. I really like Muuri for layouts. Usually there's also subtle interaction physics going on when building such libs in unexpected places (such as resizing and drag N drop speed curves), which you should tweak to your taste.
For framework, React wants to own and mediate the DOM via virtual tree, which is a major bottleneck when you need direct control over focus/selection/keyboard routing or hardware accelerated canvases. Instead, look at Svelte or Solid.js, as they integrate nicely with imperative DOM-oriented JS libraries and don't require heavy wrappers or indirect references for the 'unfriendlier' DOM nodes like canvases, scroll containers and so on.
If you're building an OS-like UI, you should also care about state and be sure you have direct control over where your data lives. For example, I usually build with Solid.js and a mix of custom object and lifetime code plus Solid stores for reactive surface state.
I usually end up managing object lifetimes because I end up needing to handle messy edge cases around reference vs value semantics and state merging (e.g. keep cursor position sane after a file sync or track focus across multiple windows, especially after refresh)
For text editing, if you use Monaco, it has so many internal lifecycle hooks you want to be aware of and interact with directly, that you'll see that most of implementation will end up outside classic frontend lib fast and I'd rather build the thing instead of bridges and wrappers to talk with a high-level framework.
All in all, you probably want to own a lot of state and behaviour yourself, and add a cooperating framework on top instead of an all-encompassing one.