feat: add query parameter support to JavaScript WebSocket client template

[hameedkhan-12]

Description:
This PR adds support for dynamic query parameters in the JavaScript WebSocket client template.
It allows developers to pass query parameters when creating a WebSocket client which are then properly encoded into the URL.
This ensures compatibility with AsyncAPI channel bindings that require query parameters and improves flexibility for client initialization.

Changes include:

-Extract query parameters from AsyncAPI channel bindings
-Update constructor to accept dynamic query parameter arguments
-Build URL query string using URLSearchParams for proper encoding
-Add comprehensive unit tests with 100% code coverage
-Update integration test snapshots

Closes #1957

Summary by CodeRabbit

Release Notes

• New Features

  • JavaScript WebSocket client template now supports query parameters in the generated constructor, allowing parameters to be appended to WebSocket URLs.

• Tests

  • Added integration tests for WebSocket client constructor with query parameters.

[changeset-bot]

🦋 Changeset detected

Latest commit: 127a10d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@asyncapi/generator	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[asyncapi-bot]

What reviewer looks at during PR review

The 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.

1. PR Title: Use a concise title that follows our Conventional Commits guidelines and clearly summarizes the change using imperative mood (it means spoken or written as if giving a command or instruction, like "add new helper for listing operations")

   Note - In Generator, prepend feat: or fix: in PR title only when PATCH/MINOR release must be triggered.

2. PR Description: Clearly explain the issue being solved, summarize the changes made, and mention the related issue.

   Note - In Generator, we use Maintainers Work board to track progress. Ensure the PR Description includes Resolves #<issue-number> or Fixes #<issue-number> this will automatically close the linked issue when the PR is merged and helps automate the maintainers workflow.

3. Documentation: Update the relevant Generator documentation to accurately reflect the changes introduced in the PR, ensuring users and contributors have up-to-date guidance.

4. Comments and JSDoc: Write clear and consistent JSDoc comments for functions, including parameter types, return values, and error conditions, so others can easily understand and use the code.

5. DRY Code: Ensure the code follows the Don't Repeat Yourself principle. Look out for duplicate logic that can be reused.

6. Test Coverage: Ensure the new code is well-tested with meaningful test cases that pass consistently and cover all relevant edge cases.

7. Commit History: Contributors should avoid force-pushing as much as possible. It makes it harder to track incremental changes and review the latest updates.

8. Template Design Principles Alignment: While reviewing template-related changes in the packages/ directory, ensure they align with the Assumptions and Principles. If any principle feels outdated or no longer applicable, start a discussion these principles are meant to evolve with the project.

9. Reduce Scope When Needed: If an issue or PR feels too large or complex, consider splitting it and creating follow-up issues. Smaller, focused PRs are easier to review and merge.

10. Bot Comments: As reviewers, check that contributors have appropriately addressed comments or suggestions made by automated bots. If there are bot comments the reviewer disagrees with, react to them or mark them as resolved, so the review history remains clear and accurate.

[github-actions]

Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[coderabbitai]

📝 Walkthrough

Walkthrough

The pull request adds query parameter support to the JavaScript WebSocket client template by extracting parameters from AsyncAPI channel bindings, dynamically generating constructor signatures and JSDoc documentation, and conditionally appending query parameters to the WebSocket URL using URLSearchParams.

Changes

Cohort / File(s)	Summary
Documentation .changeset/feat-websocket-js-query-params.md	Changelog entry documenting the addition of query parameter support to the JavaScript WebSocket client template.
Component Layer packages/templates/clients/websocket/javascript/components/ClientClass.js, packages/templates/clients/websocket/javascript/components/Constructor.js	Updated component signatures to accept and propagate query parameters. Constructor introduces three helper functions to dynamically generate constructor signatures, JSDoc documentation, and parameter initialization code based on extracted query parameter names.
Template Integration packages/templates/clients/websocket/javascript/template/client.js.js	Imports getQueryParams from generator-helpers, computes query parameters from AsyncAPI channels, and passes them to ClientClass component.
Test Coverage packages/templates/clients/websocket/javascript/test/components/Constructor.test.js	Integration test suite with snapshot testing across four scenarios: with serverUrl, without serverUrl or query, undefined query, and serverUrl with query parameters.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title clearly and concisely summarizes the main change using imperative mood with appropriate feat: prefix for a minor version update.
Linked Issues check	✅ Passed	The pull request successfully implements all coding requirements from issue #1957: extracts query parameters from channel bindings, updates constructor to accept query parameter arguments, builds properly encoded query strings using URLSearchParams, and adds comprehensive tests.
Out of Scope Changes check	✅ Passed	All changes are directly related to implementing query parameter support for the JavaScript WebSocket client template as specified in issue #1957; no out-of-scope changes detected.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments

packages/templates/clients/websocket/javascript/components/Constructor.js (3)

6-6: Inconsistent guard: query truthiness vs queryParamsArray.length produces unnecessary boilerplate for empty Maps.

The helper functions (Lines 8-28) correctly guard against empty query params via !queryParamsArray || queryParamsArray.length === 0, but Line 38 only checks query ?. If query is a truthy but empty Map, the generated code will include the params/URLSearchParams boilerplate with no actual parameters — functionally harmless but noisy in the output.

Consider aligning the condition:

Proposed fix

-      query ? `
+      queryParamsArray && queryParamsArray.length > 0 ? `

Also applies to: 37-43

---

23-28: Falsy-value check silently drops valid param values like 0 or "".

Line 27 generates if (${paramName}) params['${paramName}'] = ${paramName}; — this uses a truthiness check, so a param explicitly passed as 0, "", or false won't be appended. For auth tokens this is likely fine, but for general query parameters it could be surprising.

Consider using a != null check instead if you want to allow empty strings and other falsy-but-intentional values:

Proposed fix

-    return queryParamsArray.map(([paramName]) => `\n  if (${paramName}) params['${paramName}'] = ${paramName};`).join('');
+    return queryParamsArray.map(([paramName]) => `\n  if (${paramName} != null) params['${paramName}'] = ${paramName};`).join('');

---

3-3: Missing JSDoc on the Constructor component function.

As per coding guidelines, JS functions should have clear JSDoc comments including parameter types and return values. Consider adding JSDoc for the Constructor function describing its props (serverUrl, sendOperations, query) and return value.

packages/templates/clients/websocket/javascript/test/components/Constructor.test.js (2)

22-48: Consider adding a test for query params with serverUrl=null.

The test matrix covers serverUrl ± null and query as null/undefined/present, but is missing the combination of serverUrl=null with a valid query. This would exercise the generated code path where query params are appended to the fallback URL (empty/undefined url).

---

8-8: Multiple test files rely on deeply nested relative paths to reach shared fixtures.

The ../../../../../../helpers/test/__fixtures__/ path is repeated across packages/templates/clients/websocket/{javascript,python}/test/components/*.test.js files. Creating a helper function or constant to resolve shared fixture paths would reduce maintenance burden and improve resilience to directory structure changes.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[batchu5]

Please have a look at it -> #1957 (comment)