loomgui.com ↗

Every bridge that inherits LoomBridgeBase carries a small block of state that Loom maintains for you, namespaced under loom. You don’t declare it (it’s present on every project’s bridge), and the UI reads it like any other state:

const bridge = useBridge()
bridge.state.loom.currentSceneName  // string
bridge.state.loom.viewportWidth     // number

These fields are read-only from the UI. Loom owns them; there are no actions to set them, and the values update reactively as the engine changes.

Fields

loom.* fieldTS typeWhat it is
currentSceneNamestringName of the active Unity scene. Updates on every scene change.
viewportWidthnumberLogical (CSS-pixel) width of the Loom viewport. Updates when the view resizes.
viewportHeightnumberLogical (CSS-pixel) height of the Loom viewport.
devicePixelRationumberBacking-scale factor of the viewport (e.g. 2 on Retina).
bridgeReadybooleanWhether the UI is connected to the engine.

viewportWidth / viewportHeight mirror the layout viewport the engine lays out against, so in CSS they track window.innerWidth / innerHeight, and devicePixelRatio tracks window.devicePixelRatio. Reading them through the bridge keeps them reactive and consistent with what C# sees.

Using it from the UI

Drive layout off the scene or viewport without any extra plumbing:

import { useBridge } from '@loomgui/bridge'

export default function Hud() {
  const bridge = useBridge()
  const compact = () => bridge.state.loom.viewportWidth < 900
  return (
    <div classList={{ hud: true, 'hud--compact': compact() }}>
      {/**/}
    </div>
  )
}

bridgeReady and the C# side

The same values are available to C# gameplay code through the bridge instance, which is most useful for bridgeReady:

// Has the UI attached yet?
if (GameBridge.Instance.LoomState.BridgeReady) {
  // safe to push an initial burst of state
}

bridgeReady flips to true on the first WebSocket connection and back to false when the last client disconnects. From the UI it is effectively always true once your components render: rendering means the connection is already live. So it’s primarily a signal for the C# side to know when the UI is listening.