kworkflow / kworkflow/patch-hub

Extract `app` and `ui` components to `lib` and better modularize them

Open
#7 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

code-improv refactoring
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:

  1. 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" of lore-peek.
  2. 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.
  3. 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.
  4. 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:

  1. As it turns out, we can (and probably should) extract them to compose the lore-peek library crate, albeit well-separated from the current library scope. They are (or at least, should be) stable enough to be able to be in lib.
  2. Already, these components show signs of needing to be broken down into smaller modules. For example, the App structure 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 the ui component, 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
  • rustc version: 1.79.0
  • cargo version: 1.79.0

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.