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

feat: globalState abstraction #5293

Merged
merged 2 commits into from
Jul 12, 2024
Merged

feat: globalState abstraction #5293

merged 2 commits into from
Jul 12, 2024

Conversation

justinmk3
Copy link
Contributor

Problem

We have a settings.ts module which abstracts the vscode settings interface, to gain important features such as type-checking, validation, and error handling.

The vscode globalState interface is very similar to the vscode settings interface, and has the same limitations and potential for bugs: the data is user-defined and arbitrary, thus the types are unknown and must always be runtime-checked, which is a verbose and often overlooked step.

Examples:

Solution

  • Introduce a globalState wrapper, similar to src/shared/settings.ts.
  • Migrate the redshiftState.ts module into the centralized globalState module.

License

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@justinmk3 justinmk3 force-pushed the globalstate branch 2 times, most recently from f88250f to 9b0cf22 Compare July 11, 2024 14:59
@justinmk3
Copy link
Contributor Author

/runintegrationtests

@justinmk3 justinmk3 marked this pull request as ready for review July 11, 2024 22:53
@justinmk3 justinmk3 requested a review from a team as a code owner July 11, 2024 22:53
Problem:
We have a settings.ts module which abstracts the vscode settings
interface, to gain important features such as type-checking, validation,
and error handling.
https://github.com/aws/aws-toolkit-vscode/blob/b9d5534c0879382baa5c900d14d0a2c3fdd529c5/packages/core/src/shared/settings.ts

The vscode globalState interface is very similar to the vscode settings
interface, and has the same limitations and potential for bugs: the data
is user-defined and arbitrary, thus the types are unknown and must
always be runtime-checked, which is a verbose and often overlooked step.

Examples:

- `redshiftState.ts` https://github.com/aws/aws-toolkit-vscode-staging/pull/1034/files
- https://github.com/aws/aws-toolkit-vscode/blob/8f55e40cab47ef7d25ed5faac274c3fac3f9f91c/src/shared/filesystemUtilities.ts#L228-L253
- globalState type issues related to a codewhisperer bug: aws#3060
- `aws.lastUploadedToS3Folder` https://github.com/aws/aws-toolkit-vscode/pull/3183/files
- `ExtensionUse` class https://github.com/aws/aws-toolkit-vscode/pull/3634/files
- `codewhisperer/util/globalStateUtil.test.ts` https://github.com/aws/aws-toolkit-vscode/blob/80e715bbf3e6eb354a9b6e5e327c732b89df38e3/packages/amazonq/test/unit/codewhisperer/util/globalStateUtil.test.ts

Solution:
- Introduce a `globalState` wrapper, similar to `src/shared/settings.ts`.
- Migrate the `redshiftState.ts` module into the centralized `globalState`
  module.
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