-
-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not show reply address when empty #930
Comments
Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request. |
This issue has been automatically marked as stale because it has not had recent activity 😴 It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation. There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model. Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here. Thank you for your patience ❤️ |
@charbonnierg, it looks like a checkbox cuz it was empty, which according to your suggestion, shouldn't be there in the first place if it's empty 👍🏾 |
🎉 This issue has been resolved in version 2.2.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Description
I'm mainly using NATS as a message broker, which offers request/reply on dynamic addresses which are not indicated in the message payload or message header.
Thus, when documenting my applications with Async API, I use reply channels with empty address field.
However, the asyncapi-react component still displays:
Alternatives
Maybe display a message like:
This would be True with NATS, because client can choose the reply subject when sending a request, but I'm not sure it is more informational than simply removing the message.
Reasons
Attachments
Here is the current output:
Here is the output on my fork:
Code changes can be found here
The text was updated successfully, but these errors were encountered: