Skip to content

refactor(javascript): MessageProcessor abstraction added#176

Open
Reversean wants to merge 1 commit intorefactor/breadcrumb-storefrom
refactor/message-processor
Open

refactor(javascript): MessageProcessor abstraction added#176
Reversean wants to merge 1 commit intorefactor/breadcrumb-storefrom
refactor/message-processor

Conversation

@Reversean
Copy link
Copy Markdown
Member

@Reversean Reversean commented Mar 25, 2026

Motivation

Part of the broader effort to extract environment-agnostic logic into @hawk.so/core (#151). The blocker was Catcher.formatAndSend() — addon collection (viewport, console output, raw error data) was hardcoded inline against browser APIs with no seam to override it for a different runtime.

Why MessageProcessor?

Each MessageProcessor encapsulates one piece of env-specific addon logic. The pipeline loop belongs in a future BaseCatcher; processors are registered by the concrete catcher. A future NodeCatcher registers Node-appropriate processors without touching browser code.

BreadcrumbStore follows the same pattern — core owns the interface, the browser implementation lives in the browser package.

Why ProcessingPayload?

Extracting processors exposed a latent ordering dependency: ConsoleOutputAddonMessageProcessor and DebugAddonMessageProcessor guarded on payload.addons existing, which only BrowserAddonMessageProcessor created. ProcessingPayload<T> keeps addons always initialized but structurally partial during the pipeline — each processor writes its fields freely, and the full JavaScriptAddons contract is enforced only at the send boundary.

Changes

  • core: MessageProcessor interface, ProcessingPayload<T> type, MessageHint, BreadcrumbStore abstraction, BreadcrumbsMessageProcessor
  • javascript: BrowserAddonMessageProcessor, ConsoleOutputAddonMessageProcessor, DebugAddonMessageProcessor — each encapsulates formerly inline addon logic
  • catcher: replaced inline addon collection with a sequential MessageProcessor pipeline

@Reversean Reversean changed the title refactor(javascript): MessageProcessor abstraction added and implemented in catcher event processing pipeline refactor(javascript): MessageProcessor abstraction added Mar 25, 2026
@Reversean Reversean force-pushed the refactor/message-processor branch 3 times, most recently from 3a8de71 to 3e46e20 Compare March 25, 2026 21:44
/**
* Appends `RAW_EVENT_DATA` to the event addons for debug purposes.
*/
export class DebugMessageProcessor implements MessageProcessor<'errors/javascript'> {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
export class DebugMessageProcessor implements MessageProcessor<'errors/javascript'> {
export class DebugAddonMessageProcessor implements MessageProcessor<'errors/javascript'> {

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Comment on lines +31 to +33
if (!payload.addons) {
return payload;
}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adding should not depend on each other

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Solved with custom type ProcessingPayload which inherits all addons fields but makes it optional.

@Reversean Reversean force-pushed the refactor/message-processor branch from 3e46e20 to 1704f75 Compare April 3, 2026 20:51
@Reversean Reversean force-pushed the refactor/breadcrumb-store branch from 9890ddb to afc73fa Compare April 4, 2026 09:13
@Reversean Reversean force-pushed the refactor/message-processor branch from 1704f75 to eba517d Compare April 4, 2026 09:13
…ted in catcher event processing pipeline

- MessageProcessor interface and MessageHint type
- BrowserMessageProcessor, BreadcrumbsMessageProcessor, ConsoleCatcherMessageProcessor, DebugMessageProcessor
- replaced inline addon logic with sequential MessageProcessor pipeline
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants