Using portals (modal dialog) outside a drop zone #810

mwdiaz · 2025-01-17T01:33:05Z

mwdiaz
Jan 17, 2025

Howdy! We have an implementation that essentially wraps the entire page's content in an <Uploady> provider that injects a drop zone around all children. The intention being that we'll allow dropping a file anywhere on the page to initiate an upload. The JSX ends up looking something like this (props and specific page content omitted for brevity):

<Uploady>
  <UploadDropZone>
    <>
      <PageHeader />
      <Layout>
        <PageContent>
          { /* .. other page content */ }
          <ModalUploader />
        </PageContent>
      </Layout>
    </>
  </UploadDropZone>
</Uploady>

which yields a DOM structure that basically matches the JSX:

<body>
  <div>   <!-- drop container -->
    <header>
    <main>
      <nav>
      <!-- etc -->
    </main>
  </div>
</body>

The <ModalUploader> component (which is built using React Aria components) is rendered but initially hidden, and includes a useBatchAddListener() hook to make itself visible once files are dropped on the page. When the modal is fully rendered and made visible, React Aria will render it in a portal appended to the body:

<body>
  <div>   <!-- drop container -->
    <main>
      <header>
      <nav>
      <!-- etc -->
    </main>
  </div>
  <div data-overlay-container="true">
    <div class="underlay>
      <div role="dialog">
        <!-- Uploader UI: progress bar, message for adding more files, etc -->
      </div>
    </div>
  </div>
</body>

The modal (specifically the underlay) covers the entire page and all future dragover events will bubble up through the overlay, and the drop zone will catch them even though they didn't bubble up through the DOM (due to how events work with React portals). Prior to (I believe v1.3.0) this interaction worked fine, but now that UploadDropZone uses containerElm.contains to check where the event came from, we can't rely on the prior behavior.

For now, I patched around it using pnpm to inject an extra check into isOnTarget that basically checks if (target?.closest('.underlay')) and forces Uploady to treat it as on the target. Obviously I don't want to leave this override in place long term, but I was wondering if this sort of use case might be something you would consider supporting longer term, or whether I should just rework the UX a bit to have a drop zone that's contained within the modal itself.

Thanks!

Answered by yoavniran

Apr 18, 2025

possible fix released in: 1.10.0

View full answer

yoavniran · 2025-01-19T11:37:45Z

yoavniran
Jan 19, 2025
Maintainer

Hey @mwdiaz

Sorry I didnt have time to dive into the details so if this isnt helpful let me know, but can't the required behavior be accomplished with a combination of defining your own logic in a shouldHandleDrag callback + setting enableOnContains prop to false?

4 replies

mwdiaz Jan 21, 2025
Author

Thanks for the response @yoavniran!

Unfortunately, this won't work for us because with this specific DOM structure it isn't ever possible for the dragenter event to fire on a target that's the container element for the drop zone (it will be "covered" by the modal) — which means this check will always return false if enableOnContains is also false and, in turn means isHandling will always be false here regardless of a shouldHandleDrag callback. What we really need is something equivalent to an enableOnReactPortalContains since the "contains" check is specific to the React tree and not the DOM tree. But of course the actual events the browser is firing are for the DOM tree, so the fact a dragenter bubbles up to a non-DOM-descendent parent element is a (perhaps unfortunate) React implementation detail.

It occurred to me over the weekend that perhaps that containerElm?.contains(target) isn't the right thing here. Maybe there's a way to look at both e.target and e.currentTarget to detect when the event has bubbled up through the React tree without relying on a DOM API that has no knowledge of the React tree.

This is untested, but perhaps something like this?

return target === containerElm || allowContains && e.currentTarget !== target;

mwdiaz Jan 21, 2025
Author

Another potential option might be to make shouldHandleDrag much stronger in the sense that it could completely determine isHandling without any associated isOnTarget check.

yoavniran Jan 22, 2025
Maintainer

I will try to look into this in the next few days.
In the meantime, if you can create a simple reproducing example that I can work on, it will be extremely useful.
thanks

mwdiaz Jan 23, 2025
Author

Here's a repo with a basic example: https://github.com/mwdiaz/uploady-modal.

The main branch includes an implementation that demonstrates the issue and with-pnpm-override uses pnpm to patch @rpldy/upload-drop-zone as discussed above in order to allow the drag event to propagate through the React portal boundary. Make sure to run pnpm install when switching between the two branches to ensure node_modules reflects the correct patch state.

yoavniran · 2025-04-18T12:52:34Z

yoavniran
Apr 18, 2025
Maintainer

possible fix released in: 1.10.0

1 reply

mwdiaz Apr 18, 2025
Author

Thanks! I'm going to try this out next week.

Uh oh!

Using portals (modal dialog) outside a drop zone #810

Uh oh!

Uh oh!

mwdiaz Jan 17, 2025

Replies: 2 comments · 5 replies

Uh oh!

yoavniran Jan 19, 2025 Maintainer

Uh oh!

Uh oh!

mwdiaz Jan 21, 2025 Author

Uh oh!

mwdiaz Jan 21, 2025 Author

Uh oh!

yoavniran Jan 22, 2025 Maintainer

Uh oh!

mwdiaz Jan 23, 2025 Author

Uh oh!

yoavniran Apr 18, 2025 Maintainer

Uh oh!

mwdiaz Apr 18, 2025 Author

mwdiaz
Jan 17, 2025

Replies: 2 comments 5 replies

yoavniran
Jan 19, 2025
Maintainer

mwdiaz Jan 21, 2025
Author

mwdiaz Jan 21, 2025
Author

yoavniran Jan 22, 2025
Maintainer

mwdiaz Jan 23, 2025
Author

yoavniran
Apr 18, 2025
Maintainer

mwdiaz Apr 18, 2025
Author