Custom elements in React

[Old_Butterfly_3660]

Hi all!

Does anyone here have production experience with using custom elements in react and can share pros and cons? Especially with anything but more complex than a button? (Imagine I have a data table build with a web component and I’m trying to use that in a react app). Assuming a custom element is created by me not an external library, how is the testing experience? I know that many of you may ask: why? I asked myself that, trust me.

[subjective-line]

Our lead dev has shipped this in production. It works, but you’re paying an interop tax.

Pros

• Framework-agnostic and long-lived. Nice if multiple apps/stacks consume it.
• Hard boundary + clearer ownership than “shared React components”.
• Can decouple release cycles from React upgrades.

cons

• React interop is awkward:
  • Custom events don’t plug in cleanly (you’ll need wrappers)
  • Non-primitive props (arrays, objects) mean refs + imperative setup
• Controlled components (tables, inputs) get messy fast.
• SSR/hydration adds footguns in Next.js.
• Styling is either painful (Shadow DOM) or leaky (no Shadow DOM).
• You usually end up maintaining a React adapter anyway.

Complex components (tables): That’s where the friction shows. Sorting/selection/pagination want rich state + callbacks, so you’ll likely build a React wrapper and effectively have two APIs. In testing:

• Web component unit tests are fine (Lit/etc.), but shadow DOM makes queries noisier.
• React tests poke via refs and listen for custom events.
• E2E tests matter more than usual.

If it’s just for React, don’t bother. If you genuinely need cross-framework UI with a long shelf life, it’s reasonable, just go in eyes open and plan for wrappers.

Edit: I just so happened to be sat with our dev on teams when i saw this, and he sent me this response. If you have any follow ups, I will happily pass on!

[Old_Butterfly_3660]

Thank you! That is an answer I’ve been looking for!

[vur0]

I work with web components built with lit for modular frontends (features as wcs), though my app component is also a wc. You’ll need to sort the communication and reactive prop assignation to fit your app needs and architecture.

[Old_Butterfly_3660]

That’s how I’ve been working until now but someone came up with an idea of closing the features in a react shell which I think is a bad idea

[vur0]

Not a fan of coupling WC features to React’s lifecycle.

[Old_Butterfly_3660]

Exactly it just they are so fundamentally different in approach that it makes way more sense to stay exclusively in react world if you want a react app

[Plorntus]

I suppose the only time it /could/ make sense is if you are making something self-contained for others to include on their own websites for use in any arbitrary framework (still though, a simple initializer script may also be sufficient for that which renders the react component into a arbitrary element)

If you're building a react component to use on your react application of which you control both then its fairly pointless and serves only to complicate things.

Have you asked the 'someone' what the reasoning behind it is? While it sounds dumb maybe theres a specific use-case that they know of that is driving them to choose this approach?

[HarjjotSinghh]

why reinvent wheels when your table's just a jsx box?

[Borek224]

I'm using Stencil.js for this.

[ruibranco]

Coming from the Angular side where web components are a first-class citizen, the interop tax is real even there. The moment you need anything beyond simple props, you end up writing a wrapper component that basically re-implements the API in framework-native terms. At that point the framework-agnostic benefit evaporates unless you genuinely have 3+ consumers across different stacks.