-
Notifications
You must be signed in to change notification settings - Fork 78
PDPDEVTOOL-6272: Create UI to provide Feedback Loop for DevAssist #971
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
base: dev
Are you sure you want to change the base?
PDPDEVTOOL-6272: Create UI to provide Feedback Loop for DevAssist #971
Conversation
…op-UI # Conflicts: # packages/vscode-extension/messages.json # packages/vscode-extension/src/service/TranslationKeys.ts
| <form class="content" id="feedbackForm"> | ||
| <div class="row"> | ||
| <label for="feedback">Your Feedback</label> | ||
| <textarea id="feedback" name="feedback" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe you should add the maxlength property
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this proposal.
If we showed the remaining characters available count on the textarea (such that we display 0 when maxLength is archieved) then maybe this would be a better experience (HTML wouldn't let you type further).
But this isn't the case and I think the current Alert is more User Friendly.
Let's take this to Kostya and see what he thinks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
went with maxLength anyways.
| } | ||
| }, | ||
| FEEDBACK_FORM: { | ||
| VALIDATION_ERROR: 'DEVASSIST_SERVICE_FEEDBACK_FORM_VALIDATION_ERROR', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe you can create a group for generic errors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I renamed the message to make it clearer. Let me know what you think
| // Send request to NetSuite Backend through Proxy | ||
| try { | ||
| const currentProxySettings = getDevAssistCurrentSettings(); | ||
| const response = await fetch(`http://127.0.0.1:${currentProxySettings.localPort}/api/internal/devassist/feedback`, { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The path can be a constant value into the class file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reused the ApplicatinConstants instead of writing URL directly.
This change is better for maintainability, but is less clear IMO. Let me know if it's okay
| vsLogger.error("Feedback Form External Failure: " + response.status + ' ' + response.statusText); | ||
| vsLogger.error(''); | ||
|
|
||
| if (response.status === 403) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be a constant value, i.e. HTTP_FORBIDDEN = 403
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added HTTP_STATUS to Node Application constants and reused it here as well as in the SuiteCLoudAuthProxyService.js
| } | ||
| } | ||
| } catch (e) { | ||
| vsLogger.printTimestamp(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not very fond of large lines of code inside an exception catch. Maybe (optional) can you put it inside a method so does not look like a flow control instead of an exception
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nesting within Nesting within nesting... If possible I'd like to refuse this change
|
|
||
| const handleWebviewMessage = async (webviewMessage : any, feedbackFormCSSFilePath : string) : Promise<void> => { | ||
| switch (webviewMessage.type) { | ||
| case WEBVIEW_EVENTS.SUBMIT_FEEDBACK: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see too much code into sentences swich case that should be brief. Maybe you can wrap the lines of code for each case into functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with Carol. I would extract logic for each case into a method to improve code readability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The deed is done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good for me. If David agrees we can close this comment
| const infoMessage: string = translationService.getMessage(DEVASSIST_SERVICE.IS_RUNNING.NOTIFICATION, proxyUrl); | ||
| const buttonsAndActions: { buttonMessage: string, buttonAction: () => void }[] = [ | ||
| { | ||
| buttonMessage: translationService.getMessage(BUTTONS.SEE_DETAILS), | ||
| buttonAction: vsNotificationService.showOutput | ||
| }, | ||
| { | ||
| buttonMessage: translationService.getMessage(DEVASSIST_SERVICE.IS_RUNNING.NOTIFICATION_BUTTON), | ||
| buttonAction: () => { | ||
| vscode.commands.executeCommand('suitecloud.opendevassistfeedbackform') | ||
| } | ||
| }, | ||
| ]; | ||
| vsNotificationService.showCommandInfoWithSpecificButtonsAndActions(infoMessage, buttonsAndActions); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we extract this logic to a method to improve code readability?
I have some suggestions:
showDevAssistIsRunningNotificationshowDevAssistStartNotificationshowStartServiceNotificationshowStartDevAssistNotificationshowDevAssistStartedNotification
I'm kind of asking to replicate what it is done on showDevAssistStartUpNotification.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
| ] | ||
|
|
||
| let feedbackFormPanel: vscode.WebviewPanel | undefined; | ||
| let vscodeExtensionMediaPath : string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to have a service that can get the html content instead of constructing the path each time. It will make the implementation cleaner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implemented a MediaFileService (naming could be improved).
It mostly does what we discussed, the only limitation being that CSS file paths must be relative to the VSCode.WebView. Therefore, the cssUri must be calculated on the WebViewController and passed to the MediaFileService.
|
|
||
| // Handle messages/events sent from the webview | ||
| feedbackFormPanel.webview.onDidReceiveMessage( | ||
| (webviewMessage) => handleWebviewMessage(webviewMessage, feedbackFormCSSFilePath), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I would prefer webviewEvent instead of webviewMessage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
| return true; | ||
| } | ||
|
|
||
| const handleWebviewMessage = async (webviewMessage : any, feedbackFormCSSFilePath : string) : Promise<void> => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets try to shape the webviewMessage/webviewEvent with a proper type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
|
|
||
| const handleWebviewMessage = async (webviewMessage : any, feedbackFormCSSFilePath : string) : Promise<void> => { | ||
| switch (webviewMessage.type) { | ||
| case WEBVIEW_EVENTS.SUBMIT_FEEDBACK: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good for me. If David agrees we can close this comment
On Code Review:
Missing from the code review