client-core: map each grid message to its renderer effect #468

Merged

natsukium merged 1 commit from client-core-renderer-effect into main 2026-09-26 01:25:47 +09:00

Conversation 0 Commits 1 Files changed 6 +238 -66

natsukium commented 2026-09-26 01:13:44 +09:00

Owner

Copy link

Closes #442.

Why

Every frontend that draws a felis session mirrors some grid messages into its renderer (theme/palette overrides, the rehydrate-time color reset, reverse video), and each carried its own copy of that mapping. The copies had already drifted: felis-web-component's handles only theme colors, and felis-reel was about to become a third copy.

What

• felis_client_core::renderer_effect::{RendererEffect, renderer_effect}: a pure const fn from &GridMsg to Option<RendererEffect>. It names every GridMsg variant and every ModeFlags field (no _, no ..), so a new message or mode flag fails to build until it is classified; this also closes the .. gap noted in the issue plan.
• felis-client's event handler replaces its five inline arms with renderer_effect plus an exhaustive apply_renderer_effect; CursorState and Attention handling is unchanged.
• Docs: architecture/overview.md (client-core seam: why data, not a trait) and reference/workspace.md (crate responsibilities).

The issue's second test ("felis-client routes through renderer_effect") is covered structurally instead: felis-client no longer has its own mapping, and its apply function matches RendererEffect exhaustively.

Verification

• just check green. On the first run, felis-daemon serve::tests::force_detach_evicts_every_subscriber_and_keeps_the_session failed once at load average 12. It passed 8/8 in isolation and on the full rerun, and this change does not touch the daemon.
• Unit tests pin the effect of each renderer-affecting message, including ModeFlags with every other flag set.
• pi review (sol): PASS, no findings.

Closes #442. ## Why Every frontend that draws a felis session mirrors some grid messages into its renderer (theme/palette overrides, the rehydrate-time color reset, reverse video), and each carried its own copy of that mapping. The copies had already drifted: felis-web-component's handles only theme colors, and felis-reel was about to become a third copy. ## What - `felis_client_core::renderer_effect::{RendererEffect, renderer_effect}`: a pure `const fn` from `&GridMsg` to `Option<RendererEffect>`. It names every `GridMsg` variant and every `ModeFlags` field (no `_`, no `..`), so a new message or mode flag fails to build until it is classified; this also closes the `..` gap noted in the issue plan. - felis-client's event handler replaces its five inline arms with `renderer_effect` plus an exhaustive `apply_renderer_effect`; `CursorState` and `Attention` handling is unchanged. - Docs: `architecture/overview.md` (client-core seam: why data, not a trait) and `reference/workspace.md` (crate responsibilities). The issue's second test ("felis-client routes through `renderer_effect`") is covered structurally instead: felis-client no longer has its own mapping, and its apply function matches `RendererEffect` exhaustively. ## Verification - `just check` green. On the first run, `felis-daemon serve::tests::force_detach_evicts_every_subscriber_and_keeps_the_session` failed once at load average 12. It passed 8/8 in isolation and on the full rerun, and this change does not touch the daemon. - Unit tests pin the effect of each renderer-affecting message, including `ModeFlags` with every other flag set. - pi review (sol): PASS, no findings.

natsukium added 1 commit 2026-09-26 01:13:44 +09:00

client-core: map each grid message to its renderer effect ... 3f367bde25

Every frontend that draws a felis session has to mirror some grid
messages into its renderer (theme and palette overrides, the
rehydrate-time color reset, reverse video), and each carried its own
copy of that mapping. The copies had already drifted: the web
component's handles only theme colors, in an older shape, and drops
palette, reset and reverse-video messages without an error.

`renderer_effect` in felis-client-core returns the effect as data, and
felis-client applies it with an exhaustive match. Data rather than a
renderer trait: the core cannot name a GPU renderer, and a trait defined
there could not be implemented for felis-render-wgpu's `Renderer` from a
frontend crate without a newtype in each. The function names every
`GridMsg` variant and every `ModeFlags` field, so a new message or a new
mode flag fails to build until someone decides whether the renderer
needs it.

Assisted-by: Claude Code

natsukium merged commit d84ba1b462 into main 2026-09-26 01:25:47 +09:00

natsukium deleted branch client-core-renderer-effect 2026-09-26 01:25:47 +09:00

natsukium referenced this pull request from a commit 2026-09-26 01:25:48 +09:00

client-core: map each grid message to its renderer effect (#468)

natsukium referenced this pull request from natsukium/felis-reel 2026-09-26 01:27:27 +09:00

replay: apply felis's shared renderer effect instead of a copied mapping #7

Commenting is not possible because the repository is archived.

Reviewers

No reviewers

Labels

Clear labels   

priority/P0

Must be resolved before the v0.1.0 tag

  

priority/P1

Must be settled before the first public contract freezes

  

priority/P2

Explicitly deferred until after v0.1.0

  

release/v0.1.0

Work tracked for the first tagged release

  

status/blocked

Cannot start now: waits on an upstream release, another issue, or a recorded revisit trigger

  

status/planned

Triaged with a source-grounded plan and a passed pi review; ready to implement

  

type/bug

Shipped behavior that contradicts the docs or the code's own intent; needs a product code change

  

type/design

An open scope or trade-off question; needs a recorded decision in the owning explanation doc before code

  

type/test-gap

Documented or reviewed behavior that no test pins; usually split from a review finding, needs no product code change

  

type/tracker

Parent issue that tracks child work

No labels

priority/P0

priority/P1

priority/P2

release/v0.1.0

status/blocked

status/planned

type/bug

type/design

type/test-gap

type/tracker

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

natsukium/felis!468

No description provided.