refactor: parrot message types #198
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
joao-conde
requested review from
aquelemiguel and
afonsojramos
and removed request for
aquelemiguel
afonsojramos
approved these changes
May 29, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
strings.rs) worked fine but we can do better. It becomes a bigger problem now due to #123 where we want to have mappings of translations. This means if I want to send the HelloWorld message I can do so in fr, en, or pt. If all I use is a string, I have no way of knowing which message it is and how to translate it. This PR preps the translations PR.Here we introduce the concept of message types. These types are then displayed. A future message translation implementation will take into account the server's set language and return a different string to display.
Another important topic is error handling. I did it in a way where every error was bubbled up. While intended at the time, I see now its a bit weird for the user to receive messages like "invalid token" or something of the sorts. A next PR will make the automatic conversion from ParrotError -> ParrotMessage -> sent to user. This way, we can filter specific error messages we want to display and convert those into a specific ParrotMessage and for the other errors, we just throw a generic error message.