Refactor: split handlers/mod.rs, templates/mod.rs, services/mod.rs into per-entity modules #12

New issue

Open

opened 2026-04-30 16:47:45 +00:00 by casper-stevens · 0 comments

casper-stevens commented

2026-04-30 16:47:45 +00:00

Member

Problem

Three files in hero_biz_ui do all the work for all entity types and have grown to an unmanageable size:

File	Lines
`src/web/handlers/mod.rs`	7,557
`src/web/templates/mod.rs`	8,567
`src/services/mod.rs`	2,281
Total	~18,400

Every route handler, every HTML template, and every DB operation for every entity (persons, companies, instruments, contracts, transactions, contacts, opportunities, deals, projects, tasks, milestones, comments, …) is concatenated into these three files.

This is the direct cause of the bugs tracked in issue #11. When all entity code lives in one flat file, per-entity inconsistencies — some handlers resolve related names, others don't; some update handlers preserve link fields, others hardcode None — are structurally invisible. There is no boundary that makes the omission obvious.

Contrast with `hero_biz_app`

The hero_biz_app crate already does this correctly:

src/components/
  contacts_tab.rs
  contracts_tab.rs
  deals_tab.rs
  instruments_tab.rs
  opportunities_tab.rs
  persons_tab.rs
  projects_tab.rs
  ...

One file per entity. The hero_biz_ui web layer should follow the same pattern.

Proposed structure

src/web/handlers/
  mod.rs          // router wiring only
  persons.rs
  companies.rs
  instruments.rs
  contracts.rs
  transactions.rs
  contacts.rs
  opportunities.rs
  deals.rs
  projects.rs
  tasks.rs
  milestones.rs
  comments.rs
  links.rs        // get_link_selector + save_links + update_*_links helpers

src/web/templates/
  mod.rs          // shared render helpers only
  persons.rs
  companies.rs
  ... (same split)

src/services/
  mod.rs          // Store struct + shared helpers
  persons.rs
  companies.rs
  ... (same split)

Why this matters beyond cleanliness

Issue #11 (9 list handlers with unresolved SIDs, 5 update handlers wiping link fields) would have been caught immediately if each entity had its own file — the missing lookups would stand out against the correct ones next to them.
New entity types can be added without touching a 7k-line file.
Code review diffs become readable.

## Problem Three files in `hero_biz_ui` do all the work for all entity types and have grown to an unmanageable size: | File | Lines | |---|---| | `src/web/handlers/mod.rs` | 7,557 | | `src/web/templates/mod.rs` | 8,567 | | `src/services/mod.rs` | 2,281 | | **Total** | **~18,400** | Every route handler, every HTML template, and every DB operation for every entity (persons, companies, instruments, contracts, transactions, contacts, opportunities, deals, projects, tasks, milestones, comments, …) is concatenated into these three files. This is the direct cause of the bugs tracked in issue #11. When all entity code lives in one flat file, per-entity inconsistencies — some handlers resolve related names, others don't; some update handlers preserve link fields, others hardcode `None` — are structurally invisible. There is no boundary that makes the omission obvious. ## Contrast with `hero_biz_app` The `hero_biz_app` crate already does this correctly: ``` src/components/ contacts_tab.rs contracts_tab.rs deals_tab.rs instruments_tab.rs opportunities_tab.rs persons_tab.rs projects_tab.rs ... ``` One file per entity. The `hero_biz_ui` web layer should follow the same pattern. ## Proposed structure ``` src/web/handlers/ mod.rs // router wiring only persons.rs companies.rs instruments.rs contracts.rs transactions.rs contacts.rs opportunities.rs deals.rs projects.rs tasks.rs milestones.rs comments.rs links.rs // get_link_selector + save_links + update_*_links helpers src/web/templates/ mod.rs // shared render helpers only persons.rs companies.rs ... (same split) src/services/ mod.rs // Store struct + shared helpers persons.rs companies.rs ... (same split) ``` ## Why this matters beyond cleanliness - Issue #11 (9 list handlers with unresolved SIDs, 5 update handlers wiping link fields) would have been caught immediately if each entity had its own file — the missing lookups would stand out against the correct ones next to them. - New entity types can be added without touching a 7k-line file. - Code review diffs become readable.