kworkflow / kworkflow/patch-hub

Architectural Refinements

Open
#139 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
36
Forks
17
PR merge metrics
No merged PRs in 30d

Description

Problem Overview

The current aging MVC architecture in patch-hub has grown increasingly fragile as new features have been added. The most critical architectural issue is that the system is evolving into a "big ball of mud" pattern where components become tightly coupled and responsibilities become blurred across the codebase.

The App struct serves as a central state manager that is becoming increasingly complex. This struct manages numerous responsibilities including screen state, API clients, configuration, logging, and various data collections, indicating a violation of the single responsibility principle at the architectural level.

These problems make it harder to maintain and test components.

Proposed Solution

The new architecture will have five components:

  • The event handler
  • App
  • Model
  • Viewmodels
  • View

The two new characters are Viewmodels and Views. These two traits will be used to separate the UI from the logic concerning the UI (while the Model stores the overall business logic and data). To put it simply, a Viewmodel is responsible for processing actions (such as add bookmark or send mail) that the user takes in the View (which is essentially just the UI).

The App will be the first and foremost struct initialized, holding general configuration and information about the app itself, such as the current screen, a collection of viewmodels and views. App will also be responsible for drawing the screen/view.

After initializing and drawing the first screen, the event handler takes over. Any event is sent to the corresponding ViewModel for the screen (matched with the CurrentScreen field in App).

As always, if I left anything out or if anyone has any suggestions, please let me know!

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 locating the App struct and current event handler in the Rust codebase, then trace how screen state, API clients, configuration, logging, and data collections are coordinated. Compare that flow with the proposed App, Model, Viewmodel, View, and event-handler boundaries. Done means the architecture is separated into those five components, but the issue does not specify files or tests to verify.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cli
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.