Skip to content

Conversation

@lightning-sagar
Copy link
Contributor

@lightning-sagar lightning-sagar commented Dec 13, 2025

Description

  • Refactored Installation to be language-aware instead of language-locked
  • Render AvailableOperations based on the presence of AsyncAPI operations,
    not on a specific language

Related issue(s)

Summary by CodeRabbit

  • New Features

    • Installation section always shown and accepts a language selection, displaying the correct install command for the selected language.
    • Code examples now include per-language variants (e.g., JavaScript and Python) with language-specific payload formatting.
  • Refactor

    • Available operations list is rendered only when one or more operations exist.

✏️ Tip: You can customize this high-level summary in your review settings.

@changeset-bot
Copy link

changeset-bot bot commented Dec 13, 2025

⚠️ No Changeset found

Latest commit: f0a1d49

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

@asyncapi-bot
Copy link
Contributor

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.

@coderabbitai
Copy link

coderabbitai bot commented Dec 13, 2025

📝 Walkthrough

Walkthrough

Installation now accepts a language prop and selects an install command from a map; Readme always renders Installation (passing language) and fetches operations unconditionally, rendering AvailableOperations only if operations exist; MessageExamples generates per-language examples via language-specific renderers for JavaScript and Python.

Changes

Cohort / File(s) Summary
Language-agnostic readme components
packages/components/src/components/readme/Installation.js, packages/components/src/components/readme/Readme.js, packages/components/src/components/readme/MessageExamples.js
Installation.js: changed export to Installation({ language }); added installCommands map and selects ${command} instead of a hardcoded pip install. Readme.js: always calls Installation with language; retrieves operations unconditionally and renders AvailableOperations only when operations.length > 0. MessageExamples.js: replaced a single template with a languageConfig of per-language renderers (JS, Python); iterates renderers to produce examples and applies language-specific payload formatting.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~30 minutes

Pre-merge checks and finishing touches

❌ 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%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and specifically describes the main change: refactoring README generation to remove language-specific hardcoding.
Linked Issues check ✅ Passed All changes directly address issue #1787: Installation component now accepts language prop, AvailableOperations renders based on operations presence, and hardcoded language dependencies are removed.
Out of Scope Changes check ✅ Passed All changes are within scope of issue #1787; modifications to Installation.js, Readme.js, and MessageExamples.js directly support the objective of removing language-specific hardcoding.
✨ Finishing touches
  • 📝 Generate docstrings

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 150236c and f0a1d49.

⛔ Files ignored due to path filters (3)
  • packages/components/test/components/__snapshots__/AvailableOperations.test.js.snap is excluded by !**/*.snap
  • packages/components/test/components/__snapshots__/MessageExamples.test.js.snap is excluded by !**/*.snap
  • packages/templates/clients/websocket/test/integration-test/__snapshots__/integration.test.js.snap is excluded by !**/*.snap
📒 Files selected for processing (1)
  • packages/components/src/components/readme/MessageExamples.js
🧰 Additional context used
🧬 Code graph analysis (1)
packages/components/src/components/readme/MessageExamples.js (1)
packages/components/src/components/readme/OperationHeader.js (1)
  • operationId (4-4)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
  • GitHub Check: Acceptance tests for generated templates
  • GitHub Check: Test generator as dependency with Node 24
  • GitHub Check: Test NodeJS PR - ubuntu-latest
  • GitHub Check: Test NodeJS PR - windows-latest
  • GitHub Check: Test NodeJS PR - macos-latest
🔇 Additional comments (1)
packages/components/src/components/readme/MessageExamples.js (1)

36-38: LGTM: Multi-language iteration implemented correctly.

The refactoring successfully replaces hardcoded single-language templates with a scalable multi-language approach. The iteration correctly invokes each language's render function and accumulates the results.


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

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

@lightning-sagar lightning-sagar changed the title refactor(readme): Remove language-specific hardcoding from README generation refactor(readme): remove language-specific hardcoding from README generation Dec 13, 2025
Copy link
Member

@Adi-204 Adi-204 left a comment

Choose a reason for hiding this comment

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

@lightning-sagar left few comments!

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🧹 Nitpick comments (2)
packages/components/src/components/readme/MessageExamples.js (2)

27-49: Consider adding language prop for consistency with Installation component.

Unlike Installation.js (which accepts a language prop to render language-specific commands), this component renders examples for all languages unconditionally.

For consistency and to support language-aware rendering across README components, consider accepting a language prop to filter which examples to display.

🔎 Example implementation with language prop
-export default function MessageExamples({ operation }) {
+export default function MessageExamples({ operation, language }) {
  const operationId = operation.id();
  const messages = getOperationMessages(operation) || [];

  const messageExamples = [];
  messages.forEach((message) => {
    const examples = getMessageExamples(message) || [];
    examples.forEach((example) => {
      const payload = example.payload();
-     Object.values(languageConfig).forEach(({ render }) => {
-       messageExamples.push(render(operationId, payload));
-     });
+     const languages = language ? [language] : Object.keys(languageConfig);
+     languages.forEach((lang) => {
+       const config = languageConfig[lang];
+       if (config) {
+         messageExamples.push(config.render(operationId, payload));
+       }
+     });
    });
  });

27-27: Add JSDoc documentation for the component.

The component lacks JSDoc comments explaining its purpose, parameters, and return behavior.

🔎 Example JSDoc addition
+/**
+ * Renders message examples for an AsyncAPI operation in multiple programming languages.
+ * 
+ * @param {Object} props - Component props
+ * @param {Object} props.operation - AsyncAPI operation object with id() method
+ * @param {string} [props.language] - Optional language filter (e.g., 'javascript', 'python')
+ * @returns {React.ReactElement|null} Formatted examples or null if no examples exist
+ */
export default function MessageExamples({ operation }) {

Based on coding guidelines from the PR objectives.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c0d944f and 98f18cf.

⛔ Files ignored due to path filters (3)
  • packages/components/test/components/__snapshots__/AvailableOperations.test.js.snap is excluded by !**/*.snap
  • packages/components/test/components/__snapshots__/MessageExamples.test.js.snap is excluded by !**/*.snap
  • packages/templates/clients/websocket/test/integration-test/__snapshots__/integration.test.js.snap is excluded by !**/*.snap
📒 Files selected for processing (2)
  • packages/components/src/components/readme/Installation.js
  • packages/components/src/components/readme/MessageExamples.js
🚧 Files skipped from review as they are similar to previous changes (1)
  • packages/components/src/components/readme/Installation.js
🧰 Additional context used
🧬 Code graph analysis (1)
packages/components/src/components/readme/MessageExamples.js (2)
packages/components/src/components/readme/OperationHeader.js (1)
  • operationId (4-4)
apps/react-sdk/src/renderer/renderer.ts (1)
  • render (63-77)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
  • GitHub Check: Acceptance tests for generated templates
  • GitHub Check: Test generator as dependency with Node 24
  • GitHub Check: Test NodeJS PR - windows-latest
  • GitHub Check: Test NodeJS PR - macos-latest
  • GitHub Check: Test NodeJS PR - ubuntu-latest

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 3

♻️ Duplicate comments (1)
packages/components/src/components/readme/MessageExamples.js (1)

6-7: Unused properties flagged in previous review.

The label and codeBlock properties remain unused, as noted in the previous review comment. Consider addressing that feedback by either removing these properties or documenting their intended use.

Also applies to: 16-17

🧹 Nitpick comments (1)
packages/components/src/components/readme/MessageExamples.js (1)

44-44: Consider converting operationId to snake_case for Python conventions.

JavaScript operationIds typically use camelCase (e.g., sendMessage), but Python conventions favor snake_case function names (e.g., send_message).

While not a correctness issue, converting the identifier would make examples more idiomatic for Python developers.

🔎 Suggested conversion helper

Add a utility function:

function toSnakeCase(str) {
  return str.replace(/[A-Z]/g, letter => `_${letter.toLowerCase()}`);
}

Then update line 44:

-client.${operationId}(${pythonPayload})
+client.${toSnakeCase(operationId)}(${pythonPayload})
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 762cfad and 150236c.

⛔ Files ignored due to path filters (2)
  • packages/components/test/components/__snapshots__/AvailableOperations.test.js.snap is excluded by !**/*.snap
  • packages/components/test/components/__snapshots__/MessageExamples.test.js.snap is excluded by !**/*.snap
📒 Files selected for processing (1)
  • packages/components/src/components/readme/MessageExamples.js
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
  • GitHub Check: Test generator as dependency with Node 24
  • GitHub Check: Acceptance tests for generated templates
  • GitHub Check: Test NodeJS PR - macos-latest
  • GitHub Check: Test NodeJS PR - windows-latest
  • GitHub Check: Test NodeJS PR - ubuntu-latest

@sonarqubecloud
Copy link

sonarqubecloud bot commented Jan 1, 2026

Copy link
Member

@Adi-204 Adi-204 left a comment

Choose a reason for hiding this comment

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

@lightning-sagar left few comments!

Comment on lines +15 to +23
python: {
label: 'Python',
codeBlock: 'python',
render: (operationId, payload) => `
**Example (Python):**
\`\`\`python
client.${operationId}(${JSON.stringify(payload, null, 2)})
\`\`\`
`
Copy link
Member

Choose a reason for hiding this comment

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

For python you can look at generated clients and the methods name is in snakecase but in your implementation it is camelCase which is used in js. So you can use from @asyncapi/generator-helpers https://github.com/asyncapi/generator/blob/master/packages/helpers/src/utils.js#L70 to convert operationId.

const payload = example.payload();
messageExamples.push(exampleTemplate(operationId, payload));
Object.values(languageConfig).forEach(({ render }) => {
messageExamples.push(render(operationId, payload));
Copy link
Member

Choose a reason for hiding this comment

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

you are only using render function from the lang config than why you label and codeBlock properties for every lang in config?

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.

Refactor components to not be hardcoded to one language

3 participants