Problem
setPointer in the render options suggests it's setting state for a future render, but Clay_SetPointerState actually performs immediate hit-testing against the current layout tree. The data flow is hidden behind a misleading name.
Proposal
Replace the current pointer render option and internal setPointer/getPointerOverIds pair with something like:
term.hitTest(x, y, down): PointerEvent[]
This makes the semantics clear: you pass coordinates in, you get element IDs out. No hidden state, no frame-behind confusion.
Context
Clay_SetPointerState walks the layout tree immediately and populates pointerOverIds. In our single-render() API it's called after reduce (which wraps BeginLayout/EndLayout), so it always tests against the frame that was just built. This is correct but non-obvious from the current naming.
Problem
setPointerin the render options suggests it's setting state for a future render, butClay_SetPointerStateactually performs immediate hit-testing against the current layout tree. The data flow is hidden behind a misleading name.Proposal
Replace the current
pointerrender option and internalsetPointer/getPointerOverIdspair with something like:This makes the semantics clear: you pass coordinates in, you get element IDs out. No hidden state, no frame-behind confusion.
Context
Clay_SetPointerStatewalks the layout tree immediately and populatespointerOverIds. In our single-render()API it's called afterreduce(which wrapsBeginLayout/EndLayout), so it always tests against the frame that was just built. This is correct but non-obvious from the current naming.