feat(appcomposer): load and save from VS Code buffer #4482
Conversation
packages/toolkit/package.json
Outdated
| @@ -4352,6 +4352,7 @@ | |||
| "bytes": "^3.1.2", | |||
| "cross-fetch": "^4.0.0", | |||
| "cross-spawn": "^7.0.3", | |||
| "fast-deep-equal": "^3.1.3", | |||
There was a problem hiding this comment.
Why is this needed? If it's for performance, what were the profiling / benchmark results?
There was a problem hiding this comment.
This isn't strictly required, and I don't think the performance is a major concern given that it operates with a 1 second buffer. Using JSON.stringify() on the objects would also work here if we want to avoid adding another dependency. fast-deep-equal is generally faster and is only 13kB unpacked, which is why I added it here.
There was a problem hiding this comment.
and is only 13kB unpacked
All dependencies must be maintained, and that becomes a big problem over time. :) 13kB is a lot of code which may have bugs and CVEs...
| * when at least one of the templates cannot be parsed. Comments and whitespace should not result | ||
| * in a template update. | ||
| */ | ||
| export async function templateShouldBeUpdated(oldTemplate: string, newTemplate: string) { |
There was a problem hiding this comment.
Do not create one-function-per file. Use modules to group related functionality. This module could be util.ts , for now.
| } | ||
| bufferFileChange(event, context) |
There was a problem hiding this comment.
Avoid jargon-forking. vscode calls it a textDocument so let's be consistent, since we already have many functions with that name.
| bufferFileChange(event, context) | |
| textDocumentChange(event, context) |
## Problem - Application Composer works directly off of the workspace files. Changes in VS Code will only be detected by App Composer when the user saves, and changes in Composer will immediately be saved to disk. This does not follow the standard VS Code pattern. ## Solution - This updates Application Composer to read from and write to VS Code text documents when possible, ensuring that Composer is synced with the latest user changes and giving the user more control over what changes are saved.
Problem: When deleting a resource while the template.yaml file is closed, the template would be broken. Solution: The saveFileMessageHandler should replace the entire file, so using a range from 0 to MAX_INT works with no performance penalty.
Problem
Solution
License
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.