Help using Babylon inspector in a shadow DOM

Questions
, , , ,
1

NOTE: We are currently using BabylonJS 4. Any notes below about testing were done with version 4.2.0.

TL;DR;

  • BabylonJS Inspector 4.2 does not work when running inside of a shadow DOM
  • Likely culprits are CSS-in-JS and SVG-in-JS
  • Seeking more info about Inspector architecture and suggested solutions
  • What can be done to prevent this issue in future versions?

Background
Our development team find the native Babylon Inspector extremely useful. We would like to allow our users to open the Inspector as they work with 3D models in our application. We have been using the inspector in our development environment for a while now and it was quick and easy to get working.

Problem
We recently deployed the feature to a production environment and quickly realized the way the Inspector is compiled may not compatible with our application’s architecture. We build mini-apps that run inside of a parent application, both being React applications. To prevent style conflicts and make development easier, we always render these child apps inside of a shadow DOM. This encapsulation is what breaks the inspector.

When our app loads the inspector from inside a shadow DOM, the inspector module appears to injects its styles into style tags in root of the document which means the inspector UI inside the shadow cannot access or use those styles. I didn’t dig too deep into the source code, but it makes me wonder if CSS-in-JS is being used.

Attempted Solution
I was able to fix the majority of the layout issues by copying the inspector’s source Sass files into our project so they are bundled in our app. We already handle loading the bundled stylesheets into the shadow DOM ensuring the app’s UI has access to what it needs. While this fixed most of the CSS issues, the icons weren’t styled correctly and we couldn’t interact with any of the buttons.

Next I identified additional missing classes from the Font Awesome library. Including the Font Awesome stylesheet helped get the icons to render correctly, but we still weren’t able to interact with the inspector. It appears the inspector is using Font Awesome 5 SVG-in-JS to handle icons and I suspect this may be why the interactions are not working in the inspector.

If you aren’t familiar with shadow DOM, elements inside a shadow DOM are encapsulated from everything outside of the shadow. Styles must be loaded inside the shadow for elements to access those styles. Additionally, the document cannot be called directly from within the shadow DOM.

Inspector Architecture
I’m hoping someone can help me better understand the architecture of the Inspector module to help determine whether or not it will be possible to get the inspector working in our application inside the shadow DOM. Maybe somebody with a better understanding of how the inspector was designed can help identify a solution to run the inspector inside a shadow DOM?

While searching the forum, I came across this topic where someone mentions the inspector will be updated to use css modules in the future. That would certainly help to solve our issue, but if possible, I’d love to discuss our needs with someone from the Babylon team to make sure future versions of the inspector will be compatible with web components and shadow DOMs.

Please let me know any questions you have for me or any other information I can provide to help. Thank you in advance!

2

@RaananW might have some ideas around it ?

1 Like
3

Nice! I am going to love this discussion :slight_smile:

A bit of background - the inspector was developed a few years ago, with the thought of adding a simple debug window to the babylon playground. After a while it became its own package. It was written in React (I believe the first version was 16, but not entirely sure TBH), and was (and still is) using global (S)CSS injection. We don’t use JS-in-CSS (which, IMO would actually solve the issue, if preserved to be component-based, but that’s a whole different discussion :slight_smile: ).

We have plans to modernize the entire toolset to use modules instead of global CSS. The architecture and build tools are already there, and we haver also started migrating some of the components used by the inspector and other tools to the shared-ui-components which are component based (no global injection at all).

However, this work is not highly prioritized. we have so much on the table, that this will take a little while until we get to the point that we have the time to invest in that. Until then, I think it will be important to have those discussions to see that we cater everyone using the inspector.

And a side-note - though not enforced by us in any way, we planned the inspector to be a debugging tool, not a user-facing tool. I think the main take here is that it is quite large and adds a lot to your production code. It’s not modulized and cannot be tree-shaken. Again - by no means do we say - don’t let your users use it, we just didn’t plan it to be used this way :slight_smile: . This is why it can change everything in the scene, this is why it can record your actions and changes, this is why it supports editing the metadata of an object (thanks to a community contribution). Of course, it’s only client side, so the user can only mess up their own scene, but they most certainly CAN, if they wanted to :wink:

Another small note - even if we did fix it, we will not update the 4.2 inspector. In this case you will need to upgrade Babylon’s core and inspector version. This should be quite straight forward, since babylon is backwards compatible.

Now - a small ask - would you be able to reproduce (as simple as possible) your use case, so I can inspect (pun intended?) what exactly you are trying to achieve and see what the main tasks to get it to work in your use case?

2 Likes
4

Thanks for your prompt reply with this helpful information. I will provide details here as soon as we get a code pen or repo reproducing the issue.

1 Like