Skip to content
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

Refactor to simplify and isolate chat communication workflow #51

Merged
merged 1 commit into from
Oct 3, 2024

Conversation

shruti0085
Copy link
Contributor

@shruti0085 shruti0085 commented Oct 3, 2024

Description of changes:
This change refactors the chat communication workflow to simplify and isolate responsibilities per class. This helps restrict access to certain components like browser and server to dedicated classes as defined below which in turn would help in improving testability. This design also helps easily add handling for more message types such as quick actions which returns ChatResult for rendering in the ChatUI.
Changes include:

  • AmazonQViewActionHandler is now solely responsible for parsing and handling any actions that originate from within the WebView i.e messages from WebView/Chat UI.
  • ChatCommunicationManager orchestrates handling communication between chat server and chat UI.
    • For requests to server, it takes the JSON object and converts it to the corresponding parameter Class and calls ChatMessageProvider.
    • For response received from server, it takes the response and invokes event to be sent to Chat UI
  • AmazonQWebView is responsible for handling any interactions with the webview. It registers a listener ChatUiRequestListener for OnSendToChat event and sends message to webview for display.
  • ChatMessage is the downstream layer responsbile for final communication with the AmazonQLSPServer. This class will ultimately also hold the encryption/decryption of request/response.
  • ChatMessageProvider currently only wraps communication over to ChatMessage but eventually it will house more logic that would involve handling different types of messages eg. add tab/remove tab.
  • ChatPartialResultMap has been simplified to hold a map of partial result token to tabIDs. Each chatMessage object is uniquely identified by it's tabId. If needed, this can also be further replaced in favor of direct access to the map in appropriate class.

Future refactors could further improve testability(unit tests) by changing singelton instance of these classes to interfaces.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@shruti0085 shruti0085 merged commit f1b0a8d into main Oct 3, 2024
1 check passed
@breedloj breedloj deleted the shruti0085/refactorQcomm branch November 22, 2024 17:17
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.

2 participants