feat: add registerOutgoingProcessor to JavaScript WebSocket client#2101
feat: add registerOutgoingProcessor to JavaScript WebSocket client#210110done wants to merge 7 commits into
Conversation
10done
requested review from
Adi-204,
asyncapi-bot-eve,
derberg and
magicmatatjahu
as code owners
|
What reviewer looks at during PR reviewThe following are ideal points maintainers look for during review. Reviewing these points yourself beforehand can help streamline the review process and reduce time to merge.
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds outgoing processor registration to the JavaScript WebSocket client template: a RegisterOutgoingProcessor component generates registration code, the constructor stores processors, send logic runs processors before sending, and the example registers an outgoing processor. ChangesOutgoing Processor Registration
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
packages/templates/clients/websocket/javascript/components/RegisterOutgoingProcessor.js (1)
3-17: ⚡ Quick winAdd JSDoc for the exported component function.
RegisterOutgoingProcessoris missing JSDoc. Add a function-level docblock describing purpose, return type, and that it emits runtime warning logic in generated code.As per coding guidelines, "
**/*.{js,ts,jsx,tsx}: Write clear and consistent JSDoc comments for functions, including parameter types, return values, and error conditions".🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/templates/clients/websocket/javascript/components/RegisterOutgoingProcessor.js` around lines 3 - 17, Add a JSDoc block above the exported function RegisterOutgoingProcessor describing its purpose (returns a JSX/Text snippet that renders a JS function for registering outgoing processors), the return type (JSX.Element), and noting that the generated code includes runtime warning logic when a non-function processor is provided; include tags for `@returns` {JSX.Element} and a brief description of the emitted runtime behavior (console.warn on invalid input). Ensure the docblock sits immediately above the RegisterOutgoingProcessor declaration and follows existing project JSDoc style.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@packages/templates/clients/websocket/javascript/test/components/RegisterOutgoingProcessor.test.js`:
- Around line 4-9: The test uses a snapshot for a purely presentational
component (RegisterOutgoingProcessor) which violates the template-local policy;
replace the snapshot-only test with a focused assertion that verifies the
component's static output (e.g., render(<RegisterOutgoingProcessor />) and
assert on specific DOM nodes/text or testIds using
getByText/getByRole/getByTestId), or remove the test if integration/acceptance
covers it; update the test file to import the appropriate query helpers from
your test utils and assert specific elements instead of calling
toMatchSnapshot().
---
Nitpick comments:
In
`@packages/templates/clients/websocket/javascript/components/RegisterOutgoingProcessor.js`:
- Around line 3-17: Add a JSDoc block above the exported function
RegisterOutgoingProcessor describing its purpose (returns a JSX/Text snippet
that renders a JS function for registering outgoing processors), the return type
(JSX.Element), and noting that the generated code includes runtime warning logic
when a non-function processor is provided; include tags for `@returns`
{JSX.Element} and a brief description of the emitted runtime behavior
(console.warn on invalid input). Ensure the docblock sits immediately above the
RegisterOutgoingProcessor declaration and follows existing project JSDoc style.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: fab3c219-7211-4148-b03d-7d0f37b1c6c8
⛔ Files ignored due to path filters (2)
packages/templates/clients/websocket/javascript/test/components/__snapshots__/RegisterOutgoingProcessor.test.js.snapis excluded by!**/*.snappackages/templates/clients/websocket/test/integration-test/__snapshots__/integration.test.js.javascript.snapis excluded by!**/*.snap
📒 Files selected for processing (4)
packages/templates/clients/websocket/javascript/components/ClientClass.jspackages/templates/clients/websocket/javascript/components/Constructor.jspackages/templates/clients/websocket/javascript/components/RegisterOutgoingProcessor.jspackages/templates/clients/websocket/javascript/test/components/RegisterOutgoingProcessor.test.js
Adi-204
left a comment
Adi-204
left a comment
There was a problem hiding this comment.
@10done I honestly don't get what is use of this in JS template can you modify example https://github.com/asyncapi/generator/blob/master/packages/templates/clients/websocket/javascript/example.js to show how this can be useful? Also add screenshot in PR.
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/components/src/components/SendOperations.js (1)
61-71:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd missing required JSDoc tags on generated async instance send method.
The generated JSDoc here is missing
@returnsand@async, which are required for public functions in this path. Please update this block and regenerate docs in the same PR.As per coding guidelines, "Required JSDoc tags for public functions:
@param,@returns, and@throws/@asyncwhere applicable." and "JSDoc must be regenerated and committed in the same PR ... Useturbo run docs --filter=<pkg>to regenerate."🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/components/src/components/SendOperations.js` around lines 61 - 71, The generated instance send method's JSDoc (the nonStaticMethod block for async ${methodName}(message)) is missing the required `@returns` and `@async` tags; update that JSDoc to include an `@async` tag and an explicit `@returns` description (e.g., Promise<void> or the actual resolved value) alongside the existing `@param` and `@throws` entries, then regenerate and commit the package docs in the same PR (use turbo run docs --filter=<pkg>) so the updated JSDoc is reflected in the committed docs.
🧹 Nitpick comments (1)
packages/templates/clients/websocket/javascript/example.js (1)
17-23: ⚡ Quick winReplace inline comments with JSDoc for
outgoingProcessor.Please convert this to a proper JSDoc block including parameter type, return type, and any error behavior to keep docs consistent.
As per coding guidelines, "Write clear and consistent JSDoc comments for functions, including parameter types, return values, and error conditions."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/templates/clients/websocket/javascript/example.js` around lines 17 - 23, Replace the inline comment above outgoingProcessor with a proper JSDoc block: document the function outgoingProcessor(message) with `@param` {any} message describing the incoming payload, `@returns` {{payload: any, timestamp: string}} describing the returned processed object, and an `@throws` note that JSON.stringify may throw (e.g., on circular references); place the JSDoc directly above the outgoingProcessor function declaration in example.js and keep the rest of the implementation unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@packages/components/src/components/SendOperations.js`:
- Around line 61-71: The generated instance send method's JSDoc (the
nonStaticMethod block for async ${methodName}(message)) is missing the required
`@returns` and `@async` tags; update that JSDoc to include an `@async` tag and an
explicit `@returns` description (e.g., Promise<void> or the actual resolved value)
alongside the existing `@param` and `@throws` entries, then regenerate and commit
the package docs in the same PR (use turbo run docs --filter=<pkg>) so the
updated JSDoc is reflected in the committed docs.
---
Nitpick comments:
In `@packages/templates/clients/websocket/javascript/example.js`:
- Around line 17-23: Replace the inline comment above outgoingProcessor with a
proper JSDoc block: document the function outgoingProcessor(message) with `@param`
{any} message describing the incoming payload, `@returns` {{payload: any,
timestamp: string}} describing the returned processed object, and an `@throws`
note that JSON.stringify may throw (e.g., on circular references); place the
JSDoc directly above the outgoingProcessor function declaration in example.js
and keep the rest of the implementation unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: e4c21e29-2684-4ba8-9108-d7b3c2dfc51e
⛔ Files ignored due to path filters (2)
packages/components/test/components/__snapshots__/SendOperations.test.js.snapis excluded by!**/*.snappackages/templates/clients/websocket/test/integration-test/__snapshots__/integration.test.js.javascript.snapis excluded by!**/*.snap
📒 Files selected for processing (3)
packages/components/src/components/SendOperations.jspackages/templates/clients/websocket/javascript/example.jspackages/templates/clients/websocket/javascript/test/components/RegisterOutgoingProcessor.test.js
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/templates/clients/websocket/javascript/test/components/RegisterOutgoingProcessor.test.js
|
@Adi-204 I have updated example.js to demonstrate registerOutgoingProcessor — it intercepts every outgoing message, adds a timestamp, and passes the transformed payload to the send path. Processors are now also wired into the send path in SendOperations.js so they actually run. I hope this shows how this can be useful. Let me know if you think otherwise. |
There was a problem hiding this comment.
@10done have a look at #2101 (comment) nd also run the examples by following the instructions here: https://github.com/asyncapi/generator/blob/master/packages/templates/clients/websocket/javascript/README.md
Thanks for the registerOutgoingProcessor use case it makes sense.
|
@Adi-204 Sure i will run the examples. |
|
@Adi-204 These are the screenshots from the examples run 
|
|
3 participants
Description
registerOutgoingProcessor(processor)method to the JavaScript WebSocket client template, mirroring the existing feature in the Python WebSocket clientthis.outgoingProcessors = []in the JavaScript client constructor to store registered processor functionsRegisterOutgoingProcessorcomponentRelated issue(s)
Fixes #1975
Testing Screenshots
Summary by CodeRabbit
New Features
Examples
Tests