[GH-ISSUE #540] Terminal UI project architecture - where do you handle UI logic? Tests? #392

New issue

Closed

opened 2026-03-04 01:04:35 +03:00 by kerem · 1 comment

kerem commented

2026-03-04 01:04:35 +03:00

Owner

Originally created by @buzzdan on GitHub (Dec 21, 2020).
Original GitHub issue: https://github.com/rivo/tview/issues/540

Hi,
as a TUI newbie im still looking for best practices for my project architecture.
Is it common to organise code with MVC / MVP / MVVM / Redux or any other UI architecture out there?
how do you write tests for TUI projects?

i start to have lots of UI logic code and i find myself testing everything manually for each change...

any ideas + references would be highly appreciated 🙏

Originally created by @buzzdan on GitHub (Dec 21, 2020). Original GitHub issue: https://github.com/rivo/tview/issues/540 Hi, as a TUI newbie im still looking for best practices for my project architecture. Is it common to organise code with MVC / MVP / MVVM / Redux or any other UI architecture out there? how do you write tests for TUI projects? i start to have lots of UI logic code and i find myself testing everything manually for each change... any ideas + references would be highly appreciated :pray:

kerem closed this issue

2026-03-04 01:04:35 +03:00

kerem commented

2026-03-04 01:04:36 +03:00

Author

Owner

@rivo commented on GitHub (Jan 11, 2021):

I'm not sure if there is anything special about TUIs regarding the organization of code. I would certainly separate the model from everything else. But the rest — at least when using tview — will depend on how much extra work you're willing to do to introduce more separation. tview doesn't separate "view" from "controller", for example, so if you want that, you're going to have to roll your own.

I think how you approach this will also depend on a few other factors:

How big is your project going to be? I don't think it's worth pulling in difficult abstractions when your project is ever going to be fairly small.
How many people will work on your project simultaneously? With MVC, for example, you can assign different teams to the views, the controllers, and the models. Each part may require different skills. If you're the only programmer, however, that is not a concern. (Also, I'm not sure if any designer has ever been responsible only for the visual aspect of a TUI.)
Which parts do you plan on reusing in different contexts? It probably makes sense to introduce an abstraction before copying and pasting code all over the place.

To be honest, tview was built to get people started quickly on terminal user interfaces and not so much on facilitating huge projects. It doesn't mean that that is impossible but if that is your plan I would certainly suggest exploring your different abstraction options before getting started.

Maybe someone else can weigh in here, too.

@rivo commented on GitHub (Jan 11, 2021): I'm not sure if there is anything special about TUIs regarding the organization of code. I would certainly separate the model from everything else. But the rest — at least when using `tview` — will depend on how much extra work you're willing to do to introduce more separation. `tview` doesn't separate "view" from "controller", for example, so if you want that, you're going to have to roll your own. I think how you approach this will also depend on a few other factors: - How big is your project going to be? I don't think it's worth pulling in difficult abstractions when your project is ever going to be fairly small. - How many people will work on your project simultaneously? With MVC, for example, you can assign different teams to the views, the controllers, and the models. Each part may require different skills. If you're the only programmer, however, that is not a concern. (Also, I'm not sure if any designer has ever been responsible only for the visual aspect of a TUI.) - Which parts do you plan on reusing in different contexts? It probably makes sense to introduce an abstraction before copying and pasting code all over the place. To be honest, `tview` was built to get people started quickly on terminal user interfaces and not so much on facilitating huge projects. It doesn't mean that that is impossible but if that is your plan I would certainly suggest exploring your different abstraction options before getting started. Maybe someone else can weigh in here, too.

kerem referenced this issue

2026-03-04 01:08:38 +03:00

[PR #392] [MERGED] Add Flex.Clear() method to remove all items in flexbox #936