-
Notifications
You must be signed in to change notification settings - Fork 10
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
Expand the sharedState in extension state to handle state flags for isAnalyzing and isWaiting for solution #98
Comments
ibolton336
changed the title
TODO: Expand the sharedState in extension state to handle state flags for isAnalyzing and isWaiting for solution
Expand the sharedState in extension state to handle state flags for isAnalyzing and isWaiting for solution
Nov 14, 2024
ibolton336
added a commit
that referenced
this issue
Nov 19, 2024
) - Add webview messaging for solution request and confirmation for communication between all 3 webviews. New handlers created. - When a solution is requested (getSolution command), the solution is immediately applied. - This triggers the opening of a kai fix viewer (webview panel) that displays the violation and other incidents based on lightbulb click context. - Sets up the plumbing to allow the creation of a new webview that supports opening a panel. Augmented the current webview provider to allow this. - This new panel is initialized on solution request. Resolution panel outer webview is created on startup just like the analysis webview - Was able to setup a new var for view type and pass that down when webview is initialized so that our react app can conditionally render / route to different components based on this var. So we have 2 entirely seperate webviews that can be messaged and handle requests .. we just have to grab it from the new map in extension state and make a request to it. They both are fed the same react app, we just conditionally show what is there based on the viewtype var. - Logic to handle queue for resolution panel since it is created & messaged at same time during solution request. - Opening a webview panel vs a webview has its own lifecycle that made creating the panel & then sending a message to it very interesting. The panel needs to exist and have the listener set up before it can receive messages, so needed to implement a queue system. Messages are pushed to the queue if the webview panel isnt ready and then looped through and sent once the panel exists. - Refactor the analysis view card to use PF6 card header & expansion techniques. Allows us the ability to use the dropdown as a part of the card actions. This is where the fix all button currently sits which requests solutions for all incidents within the parent violation umbrella. - Adds a lightbulb icon at the incident level for triggering single incident solution requests. TODO: - Expand the sharedState in extension state to handle state flags for isAnalyzing and isWaiting for solution. Make use of event emitters. #98 - Determine how webview reacts to analysis run from command palette directly and ensure no gaps #99 --------- Signed-off-by: Ian Bolton <[email protected]> Co-authored-by: Radoslaw Szwajkowski <[email protected]>
Central state and notifications have been added in #107 |
Picking part of this to use vscode shared state instead of inline react state. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: