#870·ink

useCursor requires component to know the position it's displayed at

Author: MacilCreated Feb 10, 2026Updated Mar 30, 2026

The new useCursor hook's setCursorPosition method requires you to specify the absolute (ink-mount-relative) coordinate to render the cursor, which is very awkward if you want to use it from a component that's not your root component or if you make a lot of use of <Box> for layouts.

For example, if we wanted to update a component like TextInput from ink-ui to use useCursor, we would need to make it take props specifying the coordinate it's rendered at (because it might be rendered after a heading or nested inside a box with borders), and depending on what the parent components render, calculating this may require the user to use measureElement on one or more <Box> elements. Needing measureElement means that the cursor can't be positioned correctly on the initial render, and it means that components may need to be built to call measureElement again on every render that may affect layout to update the coordinates for the cursor. This all really breaks the clean encapsulation of React components.

It would be much more natural if Ink provided a <Cursor /> element. Then you never have to pass a component's own coordinates to it as props, and you would never need to combine useEffect and measureElement to measure layout positioning. Updating components like ink-ui's TextInput would just take adding a <Cursor /> element in the correct position.

Alternatively, if measureElement returned x and y properties in addition to width and height (making it very similar to the web's Element.getBoundingClientRect method), then users could easily implement a <Cursor /> element on their own using useEffect and measureElement. (EDIT: This doesn't work as-is because the component wouldn't be able to detect when it has been moved and needs to re-measure its position; its useEffects won't fire if a component rendered before it shrinks or grows. If there was a usePosition hook that fired whenever a ref's rendered position changed, then this strategy could work, but it seems like a much less elegant solution compared to a native <Cursor /> element.)