Refactor to simplify and isolate chat communication workflow #51
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.
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.AmazonQWebView
is responsible for handling any interactions with the webview. It registers a listenerChatUiRequestListener
forOnSendToChat
event and sends message to webview for display.ChatMessage
is the downstream layer responsbile for final communication with theAmazonQLSPServer
. 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.