ZacharyZhang-NY
e74dafcd36
Three independently ugly bugs that all fed the same log flood:
* Electron's `WebFrameMain.send` writes every "Render frame was disposed"
to stderr via `console.error`. When the worker fans a second
agent-event past a reloading renderer, we produced thousands of
identical lines and stalled the main loop on stderr I/O. Added a
`mainFrame.detached` guard so the send is short-circuited before
Electron's own catch block fires, and installed a targeted filter in
`suppress-warnings.ts` (now actually imported from the entry point)
so the specific `console.error("Error sending from webFrameMain:"…)`
noise never reaches the terminal. Any other payload still surfaces.
* `dispatchAgentMessage` accepted the human-reader sentinel as a wake
target when an agent replied to `__board__` — `wakeAgentIfPossible`
then called `db.getAgent("__board__")`, threw, and the dispatcher
kept repeating on every send. Strip `HUMAN_SENDER_ID` at
`resolveMessageWakeTargets`, and keep a defense-in-depth guard in the
heartbeat so a stray caller (future automation fan-out) cannot
reintroduce the crash.
* Pi's skills loader rejects any SKILL.md whose frontmatter `name`
diverges from its parent directory. The four bundled `my-writing-style`
copies declared `name: writing-style-skill`, so every install emitted
a warning and dropped the skill. They also lived as orphan gitlinks
(mode 160000 without .gitmodules), and the global `*.md` gitignore
hid every other SKILL.md from version control. Fixed the frontmatter
to match the dir, converted the dangling submodules to plain trees,
and allowlisted `builtin-skills/**/*.md` so a fresh clone carries the
catalogue instead of silently losing it.
3.4 KiB
3.4 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Presenters Format Data for the View | MEDIUM | enables multiple view formats from same use case | adapt, presenter, formatting, view-model |
Presenters Format Data for the View
Presenters accept data from use cases and format it for presentation. They create view models with strings, booleans, and pre-formatted values - nothing left for the view to compute.
Incorrect (view does formatting):
// View component does formatting - logic spread across UI
function InvoiceView({ invoice }: { invoice: Invoice }) {
// Formatting logic in view
const formattedDate = new Date(invoice.dueDate).toLocaleDateString('en-US', {
month: 'long',
day: 'numeric',
year: 'numeric'
})
const formattedTotal = new Intl.NumberFormat('en-US', {
style: 'currency',
currency: invoice.currency
}).format(invoice.total / 100)
const statusColor = invoice.status === 'paid' ? 'green'
: invoice.status === 'overdue' ? 'red'
: 'yellow'
const daysOverdue = invoice.status === 'overdue'
? Math.floor((Date.now() - new Date(invoice.dueDate).getTime()) / 86400000)
: 0
return (
<div>
<span style={{ color: statusColor }}>{invoice.status.toUpperCase()}</span>
<span>Due: {formattedDate}</span>
<span>Total: {formattedTotal}</span>
{daysOverdue > 0 && <span>{daysOverdue} days overdue</span>}
</div>
)
}
Correct (presenter formats, view renders):
// presenter/InvoicePresenter.ts
interface InvoiceViewModel {
invoiceNumber: string
status: string
statusColor: 'green' | 'yellow' | 'red'
dueDate: string
total: string
overdueMessage: string | null
}
class InvoicePresenter {
present(invoice: InvoiceResult, locale: string): InvoiceViewModel {
return {
invoiceNumber: `INV-${invoice.id.padStart(6, '0')}`,
status: invoice.status.toUpperCase(),
statusColor: this.getStatusColor(invoice.status),
dueDate: this.formatDate(invoice.dueDate, locale),
total: this.formatMoney(invoice.total, invoice.currency, locale),
overdueMessage: this.getOverdueMessage(invoice)
}
}
private getStatusColor(status: string): 'green' | 'yellow' | 'red' {
const colors = { paid: 'green', pending: 'yellow', overdue: 'red' }
return colors[status] || 'yellow'
}
private formatDate(date: Date, locale: string): string {
return new Intl.DateTimeFormat(locale, {
month: 'long', day: 'numeric', year: 'numeric'
}).format(date)
}
private getOverdueMessage(invoice: InvoiceResult): string | null {
if (invoice.status !== 'overdue') return null
const days = this.calculateDaysOverdue(invoice.dueDate)
return `${days} day${days !== 1 ? 's' : ''} overdue`
}
}
// view/InvoiceView.tsx - Humble, just renders
function InvoiceView({ vm }: { vm: InvoiceViewModel }) {
return (
<div>
<span style={{ color: vm.statusColor }}>{vm.status}</span>
<span>Due: {vm.dueDate}</span>
<span>Total: {vm.total}</span>
{vm.overdueMessage && <span>{vm.overdueMessage}</span>}
</div>
)
}
Benefits:
- Formatting logic tested without UI framework
- Same use case serves different locales via different presenter configs
- View components trivially simple, easy to redesign
Reference: Clean Architecture - Presenters and Humble Objects