Support `Box` overflow and scrolling

Firstly: this library is amazing; I’m so excited to use it everywhere I possibly can. Sadly, this issue describes a use case that’s blocking me from moving forward 😦

I’m opening this issue and offering a corresponding Gitcoin bounty in hopes it will help. Thank you to anyone who can help make this happen!

Summary

This feature request seeks to cover the use case where a component may exceed the bounds of its container. Specifically, this issue seeks the following behaviors:

• Allow <Box overflow={...}>, perhaps as implemented by #393
• Allow Box components to scroll their contents. Based on my research, #393 alone is insufficient, since it doesn’t provide a way for a component to measure what its full width/height would be. (When overflow="hidden" is provided, width/height are measured based on the final component on-screen, and there seems to be no way around this)

Related

PR #393 (Add overflow prop to Box component) is mostly complete for my concerns here. I outlined my concerns with scrolling / measurements in this comment, but no idea what the right answer is.

https://github.com/vadimdemedes/goodness-squad/issues/5 describes a related use case (Fullscreen UIs). This issue doesn’t target fullscreen UIs specifically; overflow/scrolling behavior should work regardless of whether the component is going to be fullscreen or not.

Acceptance criteria

See comment below

Notes

Please let me know if the requirements could use clarification! I’m very keen to get this working 🙇

[vadimdemedes]

I think it would be interesting to have that as a separate npm package, but I’m not sure I’d want to have that in Ink itself. If you have a complicated CLI that requires scrolling areas, you might be better of with ncurses-based alternative like blessed.

[gnidan]

I think it would be interesting to have that as a separate npm package, but I’m not sure I’d want to have that in Ink itself.

@vadimdemedes I remember from my exploration into this issue that we can’t get a separate NPM package to work without a change to Ink’s rendering methods… since Ink is responsible for doing all the layout math, it needs to keep track of the “full size” dimensions as well as the computed dimensions on-screen (what I call “natural size” vs. “fixed size” above), but the problem is that there’s no way (right now) to create a react hook to report the natural size dimensions. It looks like this information gets lost somewhere deep inside the renderer (or worse, inside the Yoga/flexbox computations).

This stuff is all very confusing to me, however, since Yoga doesn’t (didn’t?) have good API documentation. Maybe I’m wrong.

Hi @gitcoinbot my code will be here https://replit.com/@codingsh/poc-ink-box-upgrade

@developerfred is this still current? It seems rather barebones, and it doesn’t currently even run at all (looks like you have a syntax error).

---

Anyway, I notice there is some movement on #412 and also I see #472 is new since I’ve spent effort investigating the state of this issue. @vadimdemedes could you please comment on what a path forward might look like? I’m fine if it is actually possible to achieve this “natural size” calculation in a separate NPM package, but I just don’t see how that’s possible.

If further coordination across existing PRs is necessary, I could potentially double the bounty and split it up across contributors/maintainers, since I really want this behavior, but mind you I’m only working with my personal funds here. But if this is a multi-person effort, I do want to recognize that and reward everyone’s efforts. This behavior is the only thing stopping me from using Ink for a number of projects of varying sizes, and I can’t move forward on those projects in a way that satisfies me (because, well, who wants to use blessed when ink exists 😉