starred/opentui

Fork 0

mirror of https://github.com/anomalyco/opentui.git synced 2026-04-25 04:55:58 +03:00

[GH-ISSUE #697] [FEATURE]: Grid Implementation for OpenTUI #186

New issue

Open

opened 2026-03-02 23:45:09 +03:00 by kerem · 4 comments

kerem commented

2026-03-02 23:45:09 +03:00

Owner

Originally created by @viralcodex on GitHub (Feb 17, 2026).
Original GitHub issue: https://github.com/anomalyco/opentui/issues/697

Hi @kommander / @simonklee ,

I was thinking of adding a grid implementation similar to CSS just like we have flex implementation already in OpenTUI.

Currently I had a bunch of buttons aligned in a grid fashion but had to use a lot of boxes in flex styles and some hardcoding to make it work in different terminal sizes to.

It works but can be better with a Grid API available also?

We can have simple options of grid cols, col-span, fraction (fr) for starters?

Would love to hear if you guys would like to include it?

I can work on it if yes 😄

Thanks

Originally created by @viralcodex on GitHub (Feb 17, 2026). Original GitHub issue: https://github.com/anomalyco/opentui/issues/697 Hi @kommander / @simonklee , I was thinking of adding a grid implementation similar to CSS just like we have flex implementation already in OpenTUI. Currently I had a bunch of buttons aligned in a grid fashion but had to use a lot of boxes in flex styles and some hardcoding to make it work in different terminal sizes to. It works but can be better with a Grid API available also? We can have simple options of grid cols, col-span, fraction (fr) for starters? Would love to hear if you guys would like to include it? I can work on it if yes 😄 Thanks

kerem added the

feature

core

labels

2026-03-02 23:45:09 +03:00

kerem commented

2026-03-02 23:45:09 +03:00

Author

Owner

@simonklee commented on GitHub (Feb 21, 2026):

We're thinking about ways to solve this that doesn't blow up from a perf perspective. Currently, if you use yoga-layout for this it causes problems. We're thinking about using this yoga layout grid pr. In tandem with some other improvements to how we use yoga that should allow us to build what you're proposing here.

Yes we want it, but need a few things to align before getting there.

@simonklee commented on GitHub (Feb 21, 2026): We're thinking about ways to solve this that doesn't blow up from a perf perspective. Currently, if you use yoga-layout for this it causes problems. We're thinking about using this [yoga layout grid pr](https://github.com/facebook/yoga/pulls?q=is%3Apr+is%3Aopen+grid). In tandem with some other improvements to how we use yoga that should allow us to build what you're proposing here. Yes we want it, but need a few things to align before getting there.

kerem commented

2026-03-02 23:45:09 +03:00

Author

Owner

@viralcodex commented on GitHub (Feb 21, 2026):

Ah ok, would love to work on it but as you are saying we need to have yoga to support it. Something I can get started with ? Or we need to wait currently?

@viralcodex commented on GitHub (Feb 21, 2026): Ah ok, would love to work on it but as you are saying we need to have yoga to support it. Something I can get started with ? Or we need to wait currently?

kerem commented

2026-03-02 23:45:10 +03:00

Author

Owner

@simonklee commented on GitHub (Feb 21, 2026):

Grids would be a great, but they're not currently blocking other work, and we don't yet have a clear picture of how the implementation should look.

My concern with starting now is that if the direction goes the wrong way from what we end up needing, it could be difficult to merge. Especially if it increases the surface area of code affected.

I'd suggest holding off until we've landed the yoga layout changes. Once that foundation is in place, we'll have a much better sense of the right approach.

Sebastian may have thoughts here too.

@simonklee commented on GitHub (Feb 21, 2026): Grids would be a great, but they're not currently blocking other work, and we don't yet have a clear picture of how the implementation should look. My concern with starting now is that if the direction goes the wrong way from what we end up needing, it could be difficult to merge. Especially if it increases the surface area of code affected. I'd suggest holding off until we've landed the yoga layout changes. Once that foundation is in place, we'll have a much better sense of the right approach. Sebastian may have thoughts here too.

kerem commented

2026-03-02 23:45:10 +03:00

Author

Owner

@viralcodex commented on GitHub (Feb 21, 2026):

Understood, and makes sense as well, will wait for the yoga changes to merge.

@viralcodex commented on GitHub (Feb 21, 2026): Understood, and makes sense as well, will wait for the yoga changes to merge.

kerem referenced this issue

2026-03-02 23:46:19 +03:00

[PR #249] [MERGED] fix(solid): init border when supporting props are present #396

kerem referenced this issue

2026-03-14 08:39:21 +03:00

[GH-ISSUE #186] difference in opentui/solid and opentui/react border implementations #810

kerem referenced this issue

2026-03-14 09:22:40 +03:00

[PR #249] [MERGED] fix(solid): init border when supporting props are present #1177