i built a framework that handles focus and input routing automatically for you -- something born out of the things that ink leaves to you, and inspired by charmbracelet's bubbletea
- hierarchical focus and input routing: the hard part of terminal UIs, solved. define focus regions with useFocusScope, compose them freely -- a text input inside a list inside a panel just works. each component owns its keys; unhandled keypresses bubble up to the right parent automatically. no global handler like useInput, no coordination code
- 15 UI components: Select, TextInput, Autocomplete, Markdown, Modal, Viewport, CodeBlock (with diff support), VirtualList, CommandPalette, and more. sensible defaults, render props for full customization
- terminal process control: spawn processes and stream output into your TUI with hooks like useSpawn and useShellOut; hand off to vim, less, or any external program and reclaim control cleanly when they exit
- screen navigation, a keybinding registry (expose a ? help menu for free), and theming included
- react 19 compatible!
docs and live interactive demos in your browser: https://giggles.zzzzion.com
quick start: npx create-giggles-app
A random arse thought, but I have never seen the phrase batteries-included a week ago, and now I've seen it like half a dozen times. Am I seriously out of date with the lingo of web dev, or did this word suddenly explode in popularity?
The fact that there are no tests is a non-starter for me. AI mostly writes them for you now, so there really is no excuse to not have them, especially for a library that people are going to depend on.
A good toolkit for Ink is much needed, although Ink itself leaves something to be desired, especially compared to https://github.com/anomalyco/opentui (bun only, used by opencode)
I tried to build a Viewport component in Ink, but after scrolling to the bottom of a list of 150 rows, Ink started to render things strangely - the top line overflowed the box bounds, and a few blank lines appeared inside the viewport. I couldn't figure out where the bug was in Ink, I somewhat suspect floating point issues somewhere in the native Yoga<->JS layer?