SpreadJS Designer with WebComponent: Shadow DOM Integration Concerns

Posted by: luisdaniel.madrigal on 4 June 2025, 12:48 pm EST

    • Post Options:
    • Link

    Posted 4 June 2025, 12:48 pm EST

    Hello,

    At our company, we are evaluating SpreadJS for integration into one of our web-based products. I’m currently developing a proof of concept (POC), and our tech stack includes LitElement, TypeScript, and Webpack. We work with a monorepo setup and have multiple web components structured as independent modules.

    I’ve successfully created a web component that embeds the SpreadJS Designer using @mescius/spread-sheets-designer, and it’s working well overall. However, I ran into some issues related to Shadow DOM integration:

    In order to make the styles apply correctly, I had to disable Shadow DOM (by overriding createRenderRoot() to return this).

    I noticed that some DOM elements are being injected directly into the body, and certain events appear to be attached at the document level rather than scoped to the component.

    My question is:

    Is there a way to configure SpreadJS Designer to fully encapsulate all DOM rendering, styles, and event bindings within a specific container element (such as a wrapper div inside a Shadow Root), so that it plays nicely with the Shadow DOM model?

    This would help us better isolate the designer within our component structure and avoid global style or event pollution.

    Thanks in advance for your guidance!

  • Posted 5 June 2025, 3:31 am EST

    Hi,

    Regarding your question — “Is there a way to configure SpreadJS Designer to fully encapsulate all DOM rendering, styles, and event bindings within a specific container element (such as a Shadow Root)?” — SpreadJS does not officially support Shadow DOM, and certain use cases may be incompatible. Currently, there are no plans to add Shadow DOM support.

    SpreadJS is designed with the assumption that the host element (i.e., the container

    used for initialization) is part of the standard document DOM. As a result, initializing SpreadJS within a Shadow Root can lead to runtime issues, such as layout and style computation failures.

    While SpreadJS does scope its styles using .gc-* class prefixes to minimize interference with global styles, it also injects UI elements (e.g., context menus, floating editors, tooltips) directly into document.body. These components depend on global styles and scripts that are not encapsulated within the Shadow DOM, which contributes to the incompatibility.

    Regards,

    Priyam

  • Posted 12 June 2025, 2:46 pm EST

    Thanks for the reply. We’re going to look for a workaround, since this library is very complete

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels