I have a custom All-in-One (AIO) component that is sometimes rendered inside a dmc.Modal. The modal and its children (and hence, the AIO component instances) are only mounted to the DOM when the modal is opened.
I need to trigger a client-side callback to initialize some drag-and-drop functionality when an AIO instance appears in the DOM. For “normal” (always-mounted) AIO instances, this works fine using a callback like Input(MyComponent.id_root(MATCH), "id") that then looks up using getElementById and does the magic.
However, for instances inside a modal (without keepMounted=True), although the callback is fired, the element isn’t present in the DOM yet, so the initialization cannot be performed.
Current Workaround:
My workaround is to have the modal-opening callback also update a dummy data-init-dragndrop property on the AIO component. But this approach is cumbersome, as developers now need to remember to do this manual trigger whenever using this AIO in an “unmounting” container.
Question:
Is there a better way to trigger a callback for each AIO component when the instance is mounted in the DOM , regardless of whether the AIO is inside a modal or any other component that controls mounting? Ideally, I’d like a solution that is robust and does not require remembering to manually synchronize triggers whenever an AIO is in an “unmounting” container.
Could you not use a dcc.Store for the “mounted” state (opened) and use that to trigger callbacks? This would make the performance more consistent, just remove the event listener before applying it.
As far as truly mounted, there isnt a single prop in dash that would handle this. The renderer mounts things that are in the layout, this would include modals as well, but swapping back and forth (even if they were with keepMounted=false) as the DashWrapper exists and would be mounted regardless of the opened status.
Each component would have to keep track of this independently, since the DashWrapper would mount immediately. At least, this is how it seems when looking at the logic for the DashWrapper.
The intersection API is a good hint. It would trigger a little “too” often, but that should be okay. Thank you!
Regarding the store I’m not sure if that would help to keep the AIO’s encapsulation intact. I would like the container to not care about implementation details of it’s children and vice versa…