Regarding documentation, comments in tens of .h files in third level directories are very user unfriendly, regardless of their quality (which seems fairly good).
You need:
1) an overview of the available functionality, design choices, aspects that need feedback and contributions etc.
2) a guide of what headers every function or macro is located in (consider fragmenting headers less, possibly adding "umbrella" headers that just include a set of the current headers that is likely to be used together)
3) generated API docs in the web site.
Thanks for insight. I will definitely consider your critic.
We're building OrbitOS (https://github.com/codehubbers/OrbitOS) - essentially a desktop operating system that runs entirely in your browser. Think Windows 95 meets modern web tech. The project includes draggable windows, snap-to-edge functionality (like Windows Aero Snap), a taskbar with live clock, built-in apps (calculator, notes, file manager), and a full theming system. It's been a fun challenge pushing the boundaries of what's possible with React and modern browser APIs.
The window management system uses framer-motion for smooth animations - windows scale in/out when opening/closing, drag with momentum physics, and snap to screen edges with visual previews. Everything worked perfectly in development, but our CI pipeline was consistently failing because Jest couldn't understand framer-motion's custom components like motion.div and AnimatePresence. When Jest tries to render these in its JSDOM environment, it gets undefined instead of actual components.
The fix was creating proper Jest mocks that preserve the component structure while eliminating the animation complexity that Jest struggles with. Instead of just mocking framer-motion to return empty objects, I mapped motion.div to regular div elements and made AnimatePresence a transparent wrapper that just renders its children.
The interesting part was maintaining test coverage for the actual window management logic. Our tests simulate real user interactions - mousedown on title bars, mousemove to screen edges, mouseup to trigger snapping. We test all the snap zones (left/right halves, quarter-screen corners, maximize on top edge) and edge cases like rapid mouse movements and zero-dimension windows. The mocking strategy preserves all this functionality while just stripping away the animation layer.
The window snapping algorithm itself is pretty neat - we calculate snap zones based on cursor proximity to screen edges with different thresholds for corners vs edges. The state management uses React Context with a reducer pattern to handle multiple windows, z-index ordering, and position/size tracking.
One thing that surprised me was how well modern browser APIs work for desktop-class interactions. We're using ResizeObserver for responsive window content, IntersectionObserver for taskbar auto-hide, and the Pointer Events API for handling both mouse and touch interactions. The File System Access API (where supported) even lets us save/load actual files to the user's computer from our web-based apps.
The project is completely open source and we're actively looking for contributors. If you're interested in systems programming, UI/UX design, or just want to see how deep the rabbit hole goes with modern web APIs, check out the repo at https://github.com/codehubbers/OrbitOS. We have good first issues tagged for newcomers, and the codebase is well-documented with architectural decision records explaining why we chose certain approaches.
Would love to hear from anyone else working on desktop-class web applications or dealing with similar testing challenges around animation libraries. Also curious about performance optimization strategies for complex React UIs - we've learned some hard lessons about what works and what doesn't when you're trying to maintain 60fps with multiple draggable windows.
The testing infrastructure we built could probably be extracted into a separate library for anyone dealing with similar framer-motion + Jest issues. Let me know if there's interest in that or if you want to dive deeper into any of the technical details.