kworkflow / kworkflow/patch-hub
Extract `app` and `ui` components to `lib` and better modularize them
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 36
- Forks
- 17
- PR merge metrics
- No merged PRs in 30d
Description
Context:
Overall, the codebase is currently being split into the following components:
src/lib.rs: Contains all the logic related to Lore API, as well as its data structure (patches, Atom feeds, and so on). Broadly, this component represents all the "back end stuff" oflore-peek.src/app.rs: Represents the state of the running application (the Model component of the MVC pattern). This structure and name are derived from this tutorial used to bootstrap the application TUI and seems on par with the Rustacean community consensus.src/ui.rs: Encapsulates all the logic to correctly draw the user interface (a View component of the MVC pattern). This component doesn't change the app state and only composes the UI elements through reading it.src/main.rs: Responsible for calling the application's setup, startup, and teardown while ALSO containing a beast of an implementation of the Controller component of the MVC pattern.
Proposal:
Although the current "front end" implementation proposes to be a vertical prototype, which means that much of components 2 to 4 will be mutated, we should aim to start better organizing them right now. In this context, components 2 and 3 (component 4 will be scrutinized in a dedicated issue) can be greatly cleaned in two ways:
- As it turns out, we can (and probably should) extract them to compose the
lore-peeklibrary crate, albeit well-separated from the current library scope. They are (or at least, should be) stable enough to be able to be inlib. - Already, these components show signs of needing to be broken down into smaller modules. For example, the
Appstructure has a field to represent the states related to consulting the latest patchsets from a target mailing list, which has well-delimited logic that can be encapsulated for better modularization and organization. In theuicomponent, this is also evident if we consider that we probably would want a dedicated UI drawn for each encapsulated subset of application states. Long story short, we must break these components down into dedicated modules/files.
Setup:
- Project branch: unstable
- Project commit hash: 75d37acc8b217d87fa14ba694c068a8f15549015
rustcversion: 1.79.0cargoversion: 1.79.0
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading src/app.rs and src/ui.rs at commit 75d37acc8b217d87fa14ba694c068a8f15549015, then inspect how src/lib.rs currently defines the library boundary. Done means app and UI components are extracted into the library crate and split into dedicated modules or files, without changing the separate controller work in src/main.rs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100