feat: mock intent implementation#270
Conversation
smoya
force-pushed
the
feature/mock_implementation
branch
from
46cb147 to
2fe851e
Compare
There was a problem hiding this comment.
@smoya and I have added all intents as we see they should be and tweaked a few things. However, we need your help in finalizing it.
I have included a review with questions I had while going over the API, feel free to add your own review as well, we want to hear your opinion 🙏
We suggest that we slightly change how we view the parser API or at least suggest how it should be seen. Instead of trying to make the API fit perfectly to the spec (so you can access all properties) what if we just focus on what makes sense from the event-driven point of view? We can still give access to the underlying model in the future, so tool developers always have the choice to go around the intent API in edge cases where this is the only choice. For example: why would we want to give access to traits? They are something for the spec to allow the inheritance of traits between messages etc.
Adopting this view these are the properties from the spec which are purposefully not added to the API:
- Traits
- Since whether a property comes from a trait or not should not matter from tooling perspective.
- Message schema format
- It is a property for parsers to know how to parse schemas, but is it relevant to include it in the API?
- Components
- What is the intent to only access messages, etc from components. I know some define messages long before channels are defined. But shouldn't those be accessed with
AsyncAPI.messages()?
- What is the intent to only access messages, etc from components. I know some define messages long before channels are defined. But shouldn't those be accessed with
Questions:
- Should we include
isEmpty()support functions for those that return an array? Or should we still usehasX()? Related parser issue: #201 - What about external docs. Would it not make sense to wrap all descriptions in a new model called
Descriptionwhich then contains all these different aspects of a description? - What functions should always return a value (i.e. not being optional)? Should we follow all required properties from the spec or? We need to remember that changing a value from required to optional is a breaking change, so the fewer the better.
|
SonarCloud Quality Gate failed.
|
|
This pull request has been automatically marked as stale because it has not had recent activity 😴 |
2 participants
Description
Related issue(s)