refactor: remove dead StaticsMap code (#17)

[adnaan]

Summary

Closes #17. The server stopped emitting the "sm" (StaticsMap) field on TreeNode in v0.8.0 when fingerprint-based statics tracking replaced the per-path ClientStructureRegistry (livetemplate/livetemplate#86). The client kept the read path and the parameter chain alive as a no-op fallback, but the underlying data has not flowed since v0.8.0 — every reachable codepath now passes `undefined`.

Changes

• types.ts — drop `staticsMap?` field from `TargetedRangeOp`.
• state/tree-renderer.ts — drop `staticsMap?` field from `RangeStateEntry`, the `sm` reads/writes (5 reads, 3 writes), the dead `_sk` lookup branch inside `renderRangeItem`, and the `staticsMap?` parameter from `renderRangeItem` and `renderItemsWithStatics`.
• state/range-dom-applier.ts — drop `staticsMap` parameter from `RenderItemFn` and 6 internal helpers (`apply`, `applyUpdateRow`, `applyInsertAfter`, `applyAppend`, `applyPrepend`, `renderItemsAtomic`, `renderAndParse`).
• livetemplate-client.ts — drop `sm` argument from the `renderItem` callback wiring.
• tests/range-dom-applier.test.ts — match the new 4-arg `renderItem` signature.

Verification

No tests referenced `StaticsMap`, `_sk`, or `"sm"` before this commit, confirming the code path was unreachable.

• `grep -rn 'staticsMap\|StaticsMap\|_sk\b\|"sm"\|\bsm:' --include='*.ts'` — 0 hits after the change
• `npm test` — 529 tests pass across 28 suites
• `npx tsc --noEmit` — clean
• `npm run build` — clean
• Pre-commit hook ran the full gate before commit (lint + tests + build)

Closes #17.

🤖 Generated with Claude Code

[claude]

Review: LGTM

This is a clean, safe dead-code removal. A few notes:

Correctness — The claim that sm has been undefined at every callsite since v0.8.0 is credible given the grep verification in the PR description. The _sk branch in renderRangeItem was unreachable as a result, so dropping it is correct.

Backward compatibility — Even if an older server still emits "sm" in its JSON, the parsed object will just carry an ignored property. No runtime breakage.

Consistency — All seven internal helpers in range-dom-applier.ts, the RenderItemFn type, and both TreeRenderer methods are updated in lockstep. The test fixture matches. No partial removal left behind.

One minor observation — getCurrentRangeStructure in tree-renderer.ts now returns { d, s } without sm, but the return type appears to be inferred. If this type is ever widened or exported, worth checking that no downstream consumer expects sm on it. Not a blocker — just something to watch.

No bugs, security issues, or quality concerns. Ready to merge.

[Copilot]

Pull request overview

Removes the long-dead client-side StaticsMap (sm) plumbing that was kept as a no-op fallback after the server moved to fingerprint-based statics tracking, simplifying the range render/apply call chain.

Changes:

• Drop staticsMap from TargetedRangeOp and internal range state (RangeStateEntry), plus remove _sk lookup logic from TreeRenderer.
• Update RangeDomApplier’s renderItem callback signature and internal helpers to no longer thread staticsMap.
• Adjust client wiring and tests to match the new renderItem(item, idx, statics, statePath?) signature.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
types.ts	Removes staticsMap from the targeted range op type.
state/tree-renderer.ts	Eliminates sm persistence/reads and _sk statics selection; simplifies renderRangeItem/renderItemsWithStatics signatures.
state/range-dom-applier.ts	Removes staticsMap from renderItem plumbing and targeted-op application helpers.
livetemplate-client.ts	Updates RangeDomApplier callback wiring to the new renderItem signature.
tests/range-dom-applier.test.ts	Updates the test fixture callback to the new renderItem signature.

Comments suppressed due to low confidence (1)

state/range-dom-applier.ts:200

• TargetedRangeOp.staticsMap was removed and apply() no longer receives/uses any StaticsMap, but canApplyTargeted() in this same file still inspects rangeStructure.sm and folds those statics into the data-key detection. This leaves a lingering dependency on the dead sm field and can make canApplyTargeted() return true based on statics that apply() will never use, which can enable the targeted-apply path incorrectly. Please remove the rangeStructure.sm branch and base the decision solely on rangeStructure.s (or otherwise align the eligibility check with the data actually used by apply).

    const { rangePath, ops, statics } = targetedOp;
    const sampleKey = this.firstKnownKey(ops);
    const container = this.findContainer(wrapper, rangePath, sampleKey);
    if (!container) {
      this.ctx.logger.debug(

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[claude]

Review

Clean, mechanical dead-code removal with no bugs or security concerns. Two observations:

Trivial redundancy in renderRangeItem (state/tree-renderer.ts): The line const itemStatics = statics; is now a no-op alias — the conditional that gave it meaning was removed. Just use statics directly downstream. Minor, but it will confuse the next reader.

Backward-compatibility note: The sm field was optional on the wire. Any older server (pre-v0.8.0) or proxy that still emits sm/_sk will now have those fields silently ignored, causing items to render with the shared statics array instead of per-item overrides. Probably intentional given the v0.8.0 cutoff, but worth a release note if there is a supported compatibility window.

Otherwise the change is consistent across all five files, the grep + tsc + test verification is solid, and the rationale is well documented. Good to merge once the alias is cleaned up.