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" of lore-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-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.
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.
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:
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.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:
rustcversion: 1.79.0cargoversion: 1.79.0