React wrapping

[wetteyve]

React Wrapper & Bridge Component for Video.js Integration

Hi everyone,

we’ve built a (mostly) standalone React wrapper for Pillarbox that we think could be useful for other integrators as well. The wrapper includes:

• A React hook + React component to mount/unmount a Video.js player in a React app on the client side.
• A generic Video.js bridge component that accepts any ReactNode, which then gets rendered into the Video.js component.

With this bridge, you can render React components directly inside Video.js components. This lets you:

• Mix and match: build custom parts in React, while relying on Video.js for everything else.
• Keep compatibility with the pillarbox-web-suite plugins, since you don’t need to replace the full Video.js UI—only the parts you want to customize.

We see this as a framework-specific approach (relevant only if you’re working with React), and we’re not sure if it makes sense to contribute directly to this repo. But if it’s aligned with the goals of the project, I’d be happy to share links, documentation, and even the plugin itself (react-vjs-bridge).

What do you think—would this be of interest to the community?

links:

• react hook & react component. please note that these are not 100% standalone yet.
• react-vjs-bridge

[amtins]

@wetteyve I find the proposition interesting and it could benefit other developers. Does that mean it fits into React's lifecycle, or do you still need to use createPortal (or whatever it's called)?

[wetteyve]

Yes — it fully fits into the React lifecycle. The components mount and unmount in sync with the VJS player’s lifecycle, so React handles them at the correct timings. On mount, the components also inherit the player instance, which means they can directly interact with the player API as needed.

The only current limitation is that React context isn’t available inside these components, since they live in their own isolated context within the player. I haven’t found a workaround for this yet, but developers can handle it by passing down any context-dependent functionality as props from the outside, rather than trying to use hooks directly inside the custom components.

[wetteyve]

https://play-web-staging.herokuapp.com/storybook/index.html?path=/docs/components-player-default--docs

here you can find a basic showcase. custom react components beeing:

• the settings button and all its content
• the episode list button and all its content
• the share button

while all the other stuff remains VJS defaults

[saddikbannani]

The Problem You're Solving is Real
What you've built addresses a core pain point. Developers often struggle with:

Lifecycle Management: Ensuring the Video.js player is correctly initialized and destroyed to prevent memory leaks in a React app. Your React hook + component approach is the perfect solution for this.

"The Wrapper Problem": How do you inject declarative React components into a UI that is managed by an external, imperative library? Your generic Video.js bridge component sounds like an elegant and powerful solution to this. It's the most exciting part of your proposal.

The "Mix and Match" Benefit is Key
Your point about not needing to replace the entire UI is crucial. Many existing React wrappers for libraries force an "all or nothing" approach. The ability to progressively enhance the Pillarbox/Video.js UI with custom React components, while keeping the battle-tested core plugins, is a fantastic feature. This lowers the barrier to adoption and makes customization much more accessible.

On Contribution Strategy
You are absolutely right to question whether it belongs directly in the main repository. Your intuition is spot-on.

Framework-Specific vs. Agnostic Core: Most large, framework-agnostic libraries (like Video.js itself) prefer to keep their core repository free of framework-specific code. This keeps the core library lean and un-opinionated.

The Ecosystem Approach: The standard and most effective approach is to release it as a separate, dedicated open-source project. Think of libraries like react-leaflet for Leaflet or react-chartjs-2 for Chart.js.

My recommendation would be:

Publish it as a standalone npm package (e.g., react-pillarbox-bridge, react-vjs-bridge as you mentioned, or similar).

Create a dedicated GitHub repository for it.

Once it's published, you can engage with the Pillarbox/Video.js maintainers to have it listed in their official documentation under a "Community Plugins" or "Ecosystem" section. This is the best of both worlds: you maintain control, and the core project can officially recommend your solution.

[jboix]

[defagos]

My recommendation would be: Stop generating posts using AI tools. Thanks in advance for your help.