react-babylonjs: writing Babylon.js scenes as React components

The engine API, expressed as elements

The pitch is that Babylon.js is a real time 3D engine with an imperative API, and this library makes most of that API declarative. The documentation puts it as letting you build your scene and components using a familiar declarative syntax with the benefits of reusable components and hooks, and says the Babylon.js API is mostly covered declaratively thanks to code generation, with even custom props allowing you to declaratively add shadows, physics, 3D models and attach 2D or 3D UI to meshes. Code generation is the mechanism and it is the reason the coverage is as wide as it is. Rather than hand-writing a wrapper for every engine class, the elements are generated from the engine's own type definitions, which means a new Babylon.js feature shows up as a new element rather than as a missing wrapper. The custom props are the part that goes beyond plain element syntax, since attaching a shadow generator or a physics body to a mesh is a relationship between objects rather than a property of one, and encoding those relationships as props on a component is what makes the scene tree declarative rather than imperative. The stated dependency footprint is narrow: no third party dependencies outside of React and babylon.js.

Version 4 needs React 19, and the upgrade path has a trap

The version story is stated up front and it is worth reading in full, because the author has flagged a mistake. The note says that react-babylonjs version 4 requires React 19, and for older React versions, meaning React below 19, you install from the maintained 3.x line with the package name and the 3.x range, which is tracked on the r18 branch. The author then adds a warning: some limited 3.x versions did support React 19, so you may get caught updating to 3.x that is now React 18 only, and not by a patch update. The retrospective comment is that two separate major versions should have been made, and that the intention at one point was to support both in the same npm package. The practical consequence is concrete. If your application is on React 18, you are on the 3.x line and you should not let a dependency resolution pull you to a 3.x build that assumes React 18 while your application is on React 19 or the other way round. The release history shows how the line stabilised, with v4.0.0 on 2026-05-26, v4.0.1 on 2026-06-01 and v4.0.2 on 2026-06-02, and React 19 support was added by a contributor according to the credits.

Context and hooks give you the scene without prop drilling

The scene, the engine and the canvas are reachable through the Context API and hooks, and the documentation describes that as providing easy access to Scene, Engine and Canvas alongside full support for hooks and compile time checks with auto-completion on elements. Installation is a single npm or yarn command, with no extra dependencies to pull in:

npm i react-babylonjs

The practical problem this solves is that a 3D scene is inherently a shared object. The engine has to exist before the scene, the scene has to exist before any mesh, and every component that touches a mesh needs a reference to the scene. Passing that down through props in a large scene tree is exactly the drilling that Context exists to remove, and a custom hook that returns the current scene reads better than a useContext call in every component. The React Native example in the documentation shows the pattern explicitly, with a provider that supplies the engine and a null canvas, and a scene declared inside it with a camera and a light. The camera is captured into state through an onCreated callback, which is the pattern for anything you need a handle to later, and the view is rendered by a separate component that receives the camera. The documentation is honest that there are no online examples for native, so that path is documented rather than demonstrated.

React Native runs the scene on a canvas you supply

The React Native integration is the part of the documentation that reveals the architecture most clearly, because it shows the engine and the view being separated. The example imports the engine view and the useEngine hook from the React Native package, the camera from the Babylon core package, and the context provider and the Scene component from react-babylonjs. The engine comes from a hook, the camera is held in component state and set through the onCreated callback, and the provider supplies the engine together with a null canvas:

<EngineCanvasContext.Provider value={{ engine, canvas: null }}>
  {engine &&
    <Scene>
      <arcRotateCamera
        name="camera1"
        onCreated={camera => setCamera(camera)}
      />
      <hemisphericLight name="light1" />
      { /* rest of declarative scene/components here */ }
    </Scene>
  }
</EngineCanvasContext.Provider>

The null canvas is the informative part. On the web, the library creates a canvas for you, so the canvas is an implementation detail of the provider. On native there is no DOM canvas to create, so the provider is handed one explicitly and the rendering is done by a separate native view component that receives the camera. That the scene is rendered only when the engine exists, with the guard in the example, is the kind of detail that shows the boundary between the React layer and the engine layer is handled deliberately. The declarative scene inside is the same scene markup you would write for the web, which is the payoff of the binding being engine-agnostic about the renderer.

Fifty sample pages and two starter projects

The examples are the documentation. The repository advertises roughly 50 sample web pages with viewable source code published on the documentation site, and the contributors list shows what those samples cover in practice. There are demos for texture handling with image textures, node parenting through a transform node, a full screen GUI, effect layers with a glow demo, and behaviours with a pointer drag example, and the hooks section has examples for hover and click, with a react-spring integration authored as a separate package. The integration stories on the site cover a GSAP timeline demo, a PIXI demo and a zustand tunnel integration, which tells you the author has spent time on the seam between a 3D scene and the wider React ecosystem rather than treating the scene as an island. Two starter projects are linked as well. One is a Create React App in JavaScript with live examples of typical and declarative usage, some of them with Redux, and the other is a Create React App in TypeScript with examples of physics and shadows. Between them they cover the two axes a newcomer has to decide on, language and feature set, and the TypeScript project is the one to look at if you want the compile time checks.

The repository is a Yarn workspace with a separate website package

The build layout is a small monorepo, and the root package metadata describes it precisely. The root package is private and declares workspaces for the library package and the website, with build, test and lint scripts that all fan out through yarn workspaces run, plus a script to start the website development server and a prepare script that installs the husky hooks. The lint-staged configuration formats every JavaScript, TypeScript, JSON, Markdown and MDX file with prettier on commit, and the dev dependencies carry the TypeScript transformer and packager from Parcel along with a prettier plugin that organises imports, which is a small detail that keeps diffs readable across a large generated file set. The engines field asks for Node 16 or newer and npm 8 or newer, and the package manager is pinned to yarn 1.22.22, which is worth noting given the current version of the library, since the 4.x line is a modern React 19 package built with an older yarn. The website is itself a workspace, and the credits record a contributor who rebuilt the pages site using rspress, rewriting how inline code samples are displayed so you can view them fullscreen, see multiple files, and toggle between code, preview and a split view, along with a playground that supports saved and shareable snippets.

Editorial conclusion

react-babylonjs is a good fit for a React team that has chosen Babylon.js and wants the scene graph to look like the rest of the component tree, particularly when the application also needs 2D and 3D UI attached to meshes, since the binding covers that rather than leaving you to project screen coordinates. It is the wrong tool for a project that has picked Three.js, and it is the wrong tool if you need React 18, since version 4 requires React 19 and the maintained alternative is the 3.x line on the r18 branch. Before adopting it, read the version note carefully, since the author records that some limited 3.x versions did support React 19 and that patching your way into 3.x can land you on a React 18 only build, and check the licensing, since no licence identifier is given for the repository. The last push was on 2026-06-02 and the most recent release is v4.0.2 from the same day.

Frequently asked questions

Official sources

1. brianzinn/react-babylonjs on GitHub
2. Issues
3. Project website
4. README
5. Releases