docs · source detection
The file behind any element.
Click something in your running app and Zidl names the component, the file, the line and the column that rendered it — then opens it in your editor.
How it resolves
Zidl runs inside your app rather than as a browser extension or a proxy, which is what makes this possible at all. Same-origin access to the DOM means it can read React internals; a tool that renders your app as pixels cannot.
The result becomes a deep link your developer can click:
cursor://file/src/components/Checkout.tsx:87:11What it needs from your build
Detection reads React debug data or build-time source attributes. Both are present in a development build and stripped from a production one — which is the right shape, because this is a tool for dev and staging.
| Build | What you get |
|---|---|
| development | Component, file, line, column, and an editor deep link. |
| staging | The same, as long as the build is not minified with debug data stripped. |
| production | The pin, the route, the surface and the steps. No file path — there is nothing left in the bundle to read. |
Pins that fail honestly
Anchors re-resolve against the live DOM every frame, tracking nested-container scroll and reflow. When an element genuinely cannot be found again component libraries that mint fresh element ids on every mount are the hard case - the pin renders nothing rather than guessing a position and pointing at the wrong component.
That is a deliberate trade. A marker that silently drifts onto a neighbouring element is worse than a missing one, because the report it produces looks correct and is not. See the step recorder for the half of the report that does not depend on anchoring at all.