rc-dock working with 13.3 but not 13.4. Component not recognize dragging
Unanswered
Mud-daubers posted this in #help-forum
Mud-daubersOP
Longshot thing, but anyone here ever tried to use rc-dock (https://ticlo.github.io/rc-dock) inside a next.js application?
I've been using it (and loving it) for a dynamic layout engine and it was working great with next.js 13.3, but I noticed today that ever since updating to next.js 13.4 last month, the rc-dock drag/snap components no longer appear when dragging, which prevents any sort of rearrangement. (think of them as snap to sides/center/tab drop zones)
I can size panels just fine and even drag them around if I pop them out to floating, so the mouse move actions are being picked up just fine, but I can just no longer dock them to anything since it acts like it doesn't register it is in mid-drag state.
It might have something to do with next.js not rerendering the contents of the panel without explicitly seeing the state change, but with the docklayout parent component marked as "use client" it should be keeping everything in the browser side and handling just like a normal react app.
It's clearly something different in next.js because I can make no change other than updating package.json and it stops working and rolling back fixes it, but I'm curious if anyone else has seen similar behavior of the docking overlay not appearing in some situations and/or if there's some way of explicitly triggering the overlay appearance or getting access to the state changes to watch for mid-dragging process.
I've been using it (and loving it) for a dynamic layout engine and it was working great with next.js 13.3, but I noticed today that ever since updating to next.js 13.4 last month, the rc-dock drag/snap components no longer appear when dragging, which prevents any sort of rearrangement. (think of them as snap to sides/center/tab drop zones)
I can size panels just fine and even drag them around if I pop them out to floating, so the mouse move actions are being picked up just fine, but I can just no longer dock them to anything since it acts like it doesn't register it is in mid-drag state.
It might have something to do with next.js not rerendering the contents of the panel without explicitly seeing the state change, but with the docklayout parent component marked as "use client" it should be keeping everything in the browser side and handling just like a normal react app.
It's clearly something different in next.js because I can make no change other than updating package.json and it stops working and rolling back fixes it, but I'm curious if anyone else has seen similar behavior of the docking overlay not appearing in some situations and/or if there's some way of explicitly triggering the overlay appearance or getting access to the state changes to watch for mid-dragging process.
7 Replies
Mud-daubersOP
I've narrowed this breaking change down to Next.js 13.4.9-canary.3 and beyond. I made an example project at and branches for the various working and nonworking things at https://github.com/aranselmo/next-js-server-rc-dock
I don't know if I should put this in as a bug or if it's something fundamental changed and I'm doing something incorrectly, but the sole difference between branches are package.json changes, so I feel like at minimum 13.4.8 to 13.4.9+ should be somehow called out as having potentially breaking changes and not as a simple version update since it clearly can potentially cause a problem.
I don't know if I should put this in as a bug or if it's something fundamental changed and I'm doing something incorrectly, but the sole difference between branches are package.json changes, so I feel like at minimum 13.4.8 to 13.4.9+ should be somehow called out as having potentially breaking changes and not as a simple version update since it clearly can potentially cause a problem.
Mud-daubersOP
I created a bug for this. I can't find a way to make rc-dock work past 13.4.9-canary.3 even unto the latest.
https://github.com/vercel/next.js/issues/54512
https://github.com/vercel/next.js/issues/54512
Mud-daubersOP
Just bumping this topic as it's still a bug in latest canary
Anyone have advice on the process to build and test my own fork of next.js code? I've never rolled my own local npm package.
I'm trying to hunt down the specific commit that broke my app per https://github.com/vercel/next.js/issues/54512 that is still broken in latest versions and everything after 13.4.9-canary.2. Something changed between 13.4.9-canary.2 and 13.4.9-canary.3 that stopped the client rc-dock layout drag component from registering and displaying docks when dragging.
But that's still 44 commits and 450 files to try to narrow down per https://github.com/aranselmo/next.js/compare/working-13.4.9-canary.2...aranselmo:next.js:nonworking-13.4.9.
So it'd be easier if I could just build my own next.js at each commit after 13.4.9-canary.3 and narrow in on exact file changes and how I can either fix my app to work with new way of doing things or identify it as an actual bug in next.js
Anyone have advice on the process to build and test my own fork of next.js code? I've never rolled my own local npm package.
I'm trying to hunt down the specific commit that broke my app per https://github.com/vercel/next.js/issues/54512 that is still broken in latest versions and everything after 13.4.9-canary.2. Something changed between 13.4.9-canary.2 and 13.4.9-canary.3 that stopped the client rc-dock layout drag component from registering and displaying docks when dragging.
But that's still 44 commits and 450 files to try to narrow down per https://github.com/aranselmo/next.js/compare/working-13.4.9-canary.2...aranselmo:next.js:nonworking-13.4.9.
So it'd be easier if I could just build my own next.js at each commit after 13.4.9-canary.3 and narrow in on exact file changes and how I can either fix my app to work with new way of doing things or identify it as an actual bug in next.js
Mud-daubersOP
So I've been able to narrow this down to the next.js 6dafc4229d1bbcf11b9a5c243f39a8e76de5a27f commit between 13.4.9-canary.2 and 13.4.9-canary.3.
That commit updated react to new version, so I guess this issue is happening due to some incompatibility of rc-dock with react@18.3.0-canary-7118f5dd7-20230705 and above.
I was able to run and step into the rc-dock code and the only thing I can figure out is before that version of react, starting a drag would initiate a render() call that would update the panel with dock-panel-dropping class that would display the drop container.
But after that update, the render() only gets called on initial render and drag never triggers it, which means there's no way to drag/drop the components.
That commit updated react to new version, so I guess this issue is happening due to some incompatibility of rc-dock with react@18.3.0-canary-7118f5dd7-20230705 and above.
I was able to run and step into the rc-dock code and the only thing I can figure out is before that version of react, starting a drag would initiate a render() call that would update the panel with dock-panel-dropping class that would display the drop container.
But after that update, the render() only gets called on initial render and drag never triggers it, which means there's no way to drag/drop the components.
Mud-daubersOP
New weird revelation, thanks to a user on the rc-dock discord, I was able to identify the rc-dock problem above doesn't apply to next.js pages routers, only app router. My stuff was all in app directory style, but moving the example into pages router worked. https://github.com/aranselmo/next-js-server-rc-dock/tree/working-with-13.4.10-pages-routers That's a pity as my entire app is written for the app router currently and I don't want to switch up, but it's one more piece of the puzzle at least. It is definitely some interaction of the default app/server rendering with however rc-dock embeds it's components.
This all clearly has something to do with defaulting to server rendering and server component roots not rerendering on drag over
This all clearly has something to do with defaulting to server rendering and server component roots not rerendering on drag over
Mud-daubersOP
On suggestion in general, I tried to add dynamic() load variants to app dir, but per https://github.com/aranselmo/next-js-server-rc-dock/tree/nonworking-with-13.4.10-dynamic-variant and comparing pages/page-client-only.tsx to app/clientonly/page.tsx, clientonly-dynamic-import/page.tsx, and clientonly-dynamic/page.tsx the app dir ones do not work but pages dir does, so something is definitely different in how pages router is loading
Mud-daubersOP
Bumping this question thread as this is still giving me trouble.
Anyone know if there's a way to force an app router page to load identically to how page router loads? Or else a way to disable SSR for an entire import and all its loaded components?
I have a third-party react library used in my application that hasn't worked in app-router since 13.4.9-canary.2, but works fine in the pages router in all versions, including latest.
Specifically the drag and drop functionality doesn't trigger properly in the app router version, though does in page version in same example project
Really don't want to have to run this portion of the app through pages route just to keep using latest nextjs
Anyone know if there's a way to force an app router page to load identically to how page router loads? Or else a way to disable SSR for an entire import and all its loaded components?
I have a third-party react library used in my application that hasn't worked in app-router since 13.4.9-canary.2, but works fine in the pages router in all versions, including latest.
Specifically the drag and drop functionality doesn't trigger properly in the app router version, though does in page version in same example project
Really don't want to have to run this portion of the app through pages route just to keep using latest nextjs