[feat] we need to refactor into a better files structure

[kubeden]

Problem to solve

The current main files are going to become large quickly, so I believe a new structure should be created, where the code for the file is as minimal as possible, and also logically separated.

Propose a new dir structure

[Udayan853]

I believe that currently tui/program.go is the biggest file and starting the refactor there seems logical.
So, I would suggest the following changes

• Refactor the Model struct (break down the responsibilities in smaller structs and embed them)
• Move Model into a dedicated package (state)
• Simplify the Update function (delegate work to sub-model update functions handlers)
• Separate utility functions into a different package and/or to a different utils.go for each package
• Move View to its own package

Implementing the above changes would lead to a directory structure that roughly looks like this

.
├── cmd
└── internal
├── cli
├── diffview
├── gitx
├── prefs
└── tui
├── handlers
│   ├── core.go
│   ├── [feature]_handler.go
│   └── utils.go
├── state
│   ├── branch_switch_wizard.go
│   ├── commit_wizard.go
│   ├── core.go
│   ├── pull_wizard.go
│   ├── search.go
│   └── [feature]_wizard.go
├── tui
│   ├── run.go
│   └── update.go
└── view

The problems I can think of with a structure like this would be

• Nesting of handlers
• Too many feature files (similar features will need to be merged at some point)

I'd like to hear your take on this

[kubeden]

I believe that currently tui/program.go is the biggest file and starting the refactor there seems logical.
So, I would suggest the following changes

• Refactor the Model struct (break down the responsibilities in smaller structs and embed them)
• Move Model into a dedicated package (state)
• Simplify the Update function (delegate work to sub-model update functions handlers)
• Separate utility functions into a different package and/or to a different utils.go for each package
• Move View to its own package

Implementing the above changes would lead to a directory structure that roughly looks like this

.
├── cmd
└── internal
├── cli
├── diffview
├── gitx
├── prefs
└── tui
├── handlers
│   ├── core.go
│   ├── [feature]_handler.go
│   └── utils.go
├── state
│   ├── branch_switch_wizard.go
│   ├── commit_wizard.go
│   ├── core.go
│   ├── pull_wizard.go
│   ├── search.go
│   └── [feature]_wizard.go
├── tui
│   ├── run.go
│   └── update.go
└── view

The problems I can think of with a structure like this would be

• Nesting of handlers
• Too many feature files (similar features will need to be merged at some point)

I'd like to hear your take on this

This sounds logical, yes. I was thinking about the same thing, although the only concern I have is with the current open PRs (which are none by the way), so this needs to happen BEFORE anyone starts doing work on any of the issues.. preferably very sson :s

[Udayan853]

I might need a day to complete all the refactors.
Since Hacktoberfest is just starting, I imagine some people may have local commits ready to PR. Should I wait a bit, or start working on it right away?

[kubeden]

Hey. You can start.

I apologise if this comes as an unwanted opinion, but if you're doing it with an LLM, I would suggest to get Codex and write one big prompt and ask it to first go and do its best to understand the entire codebase without telling it what the end goal is gonna be. After that ask it to architect a modular rewrite without changing any code, and when it does, agree and let it rip.

Claude introduces too many unwanted slop... Codex works with the cheap $20 btw.. just set it to gpt-5-high

[Udayan853]

Quick update

I’ve been working on the refactor with Claude’s help, but it’s proving larger than expected. The codebase has a lot of coupling, and the AI-generated code introduced issues (circular imports, missing functions, hallucinated packages). At my current pace this will take around 3–4 days, not 1.

To keep things moving, here are a couple of options:

• Allow other issue resolutions to run in parallel, while contributors (including me) make multiple smaller PRs for the refactor. The issue itself could also be broken into smaller scoped issues.

• Alternatively, we could have multiple contributors collaborate on this issue to reach a resolution faster.

I’ve already made some changes, though they aren’t functional yet. If helpful, I can open a draft PR so everyone can see the current state and progress.

Please let me know which approach you’d prefer.

[kubeden]

Hmm. Maybe people can start contributing, and in the meantime when you're done, I can jump in and help to introduce the new features since the commit you used to do the structure change.

P.s. if you are using Cursor, I strongly advise to try what I mentioned with gpt-5-high

Let me know