chore: consolidate duplicate ReactionService (base/ vs nostr-feed/) #78

New issue

Closed

opened 2026-05-28 07:55:08 +00:00 by padreug · 0 comments

padreug commented

2026-05-28 07:55:08 +00:00

Owner

Summary

Two ReactionService classes exist with ~24% line-level drift:

src/modules/base/nostr/ReactionService.ts (581 lines) — registered in DI via src/modules/base/index.ts:35,79 as SERVICE_TOKENS.REACTION_SERVICE. This is the live service.
src/modules/nostr-feed/services/ReactionService.ts (584 lines) — not registered in DI anywhere. The class exists in the source tree but is never instantiated. Dead code.

Both expose the same API surface (likeEvent, unlikeEvent, dislikeEvent, undislikeEvent, handleReactionEvent, handleDeletionEvent) and both contain finalizeEvent(eventTemplate, prvkeyBytes) sign-sites that need migration in the lnbits-#9 signer-abstraction phase 2. Without consolidation, the migration would have to touch both copies and risk drifting them further.

src/modules/nostr-feed/index.ts:46 already notes: // NOTE: ProfileService and ReactionService are now provided by the base module.

Concrete proposal

Delete src/modules/nostr-feed/services/ReactionService.ts.
Delete src/modules/nostr-feed/composables/useReactions.ts (mirrors src/modules/base/composables/useReactions.ts).
Update the one import that still references the local file:
- src/modules/nostr-feed/composables/useReactions.ts:3 — import type { ReactionService, EventReactions } from '../services/ReactionService' → repoint to @/modules/base/nostr/ReactionService (or delete the composable per item 2 and update consumers).
Verify the remaining base-module ReactionService preserves any behavior unique to the nostr-feed copy. From the diff: the nostr-feed copy contains a comment that "deletion monitoring is now handled by FeedService's consolidated subscription" — the base copy doesn't have that comment but the FeedService delegation pattern is the same in both. No behavioral merge required, just code consolidation.

Why this matters now

This is a blocker for cleanly migrating the bucket B (user-as-self) sign-sites off currentUser.value.prvkey per aiolabs/lnbits#9. The migration touches every finalizeEvent call in the webapp; if we leave both ReactionService files in place, we'll either migrate both (waste) or migrate one and silently leave dead-code paths that still try to read prvkey (regression risk on hot-reload or accidental re-registration).

Acceptance

nostr-feed/services/ReactionService.ts removed.
nostr-feed/composables/useReactions.ts removed (or its imports repointed).
npm run build clean.
Like / unlike / dislike / undislike flows work in nostr-feed module (NostrFeed page) and forum module (SubmissionService consumers).

Refs

Cross-session log: ~/dev/coordination/log.md entry 2026-05-28T19:45Z · lnbits → webapp,all (flagged the duplicate) and 2026-05-28T19:00Z · webapp → lnbits,all (audit).
Parent initiative: aiolabs/lnbits#9 (signer abstraction / bunker integration).

## Summary Two `ReactionService` classes exist with ~24% line-level drift: - `src/modules/base/nostr/ReactionService.ts` (581 lines) — **registered** in DI via `src/modules/base/index.ts:35,79` as `SERVICE_TOKENS.REACTION_SERVICE`. This is the live service. - `src/modules/nostr-feed/services/ReactionService.ts` (584 lines) — **not registered** in DI anywhere. The class exists in the source tree but is never instantiated. Dead code. Both expose the same API surface (`likeEvent`, `unlikeEvent`, `dislikeEvent`, `undislikeEvent`, `handleReactionEvent`, `handleDeletionEvent`) and both contain `finalizeEvent(eventTemplate, prvkeyBytes)` sign-sites that need migration in the lnbits-#9 signer-abstraction phase 2. Without consolidation, the migration would have to touch both copies and risk drifting them further. `src/modules/nostr-feed/index.ts:46` already notes: `// NOTE: ProfileService and ReactionService are now provided by the base module`. ## Concrete proposal 1. Delete `src/modules/nostr-feed/services/ReactionService.ts`. 2. Delete `src/modules/nostr-feed/composables/useReactions.ts` (mirrors `src/modules/base/composables/useReactions.ts`). 3. Update the one import that still references the local file: - `src/modules/nostr-feed/composables/useReactions.ts:3` — `import type { ReactionService, EventReactions } from '../services/ReactionService'` → repoint to `@/modules/base/nostr/ReactionService` (or delete the composable per item 2 and update consumers). 4. Verify the remaining base-module ReactionService preserves any behavior unique to the nostr-feed copy. From the diff: the nostr-feed copy contains a comment that "deletion monitoring is now handled by FeedService's consolidated subscription" — the base copy doesn't have that comment but the FeedService delegation pattern is the same in both. No behavioral merge required, just code consolidation. ## Why this matters now This is a **blocker** for cleanly migrating the bucket B (user-as-self) sign-sites off `currentUser.value.prvkey` per `aiolabs/lnbits#9`. The migration touches every `finalizeEvent` call in the webapp; if we leave both ReactionService files in place, we'll either migrate both (waste) or migrate one and silently leave dead-code paths that still try to read prvkey (regression risk on hot-reload or accidental re-registration). ## Acceptance - [ ] `nostr-feed/services/ReactionService.ts` removed. - [ ] `nostr-feed/composables/useReactions.ts` removed (or its imports repointed). - [ ] `npm run build` clean. - [ ] Like / unlike / dislike / undislike flows work in nostr-feed module (NostrFeed page) and forum module (SubmissionService consumers). ## Refs - Cross-session log: `~/dev/coordination/log.md` entry `2026-05-28T19:45Z · lnbits → webapp,all` (flagged the duplicate) and `2026-05-28T19:00Z · webapp → lnbits,all` (audit). - Parent initiative: `aiolabs/lnbits#9` (signer abstraction / bunker integration).

padreug added the

app:webapp

enhancement

labels

2026-05-28 07:55:24 +00:00

padreug referenced this issue from a commit

2026-05-28 14:51:55 +00:00

chore(nostr-feed): delete dead-code ReactionService + useReactions duplicates

padreug referenced this issue from a pull request that will close it,

2026-05-28 14:54:07 +00:00

chore(nostr-feed): delete dead-code ReactionService + useReactions duplicates #80

padreug referenced this issue