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

Improve type-safety: use autogenerated types across frontend codebase (part 1) #3331

Closed
Tracked by #3338
brojd opened this issue Nov 13, 2023 · 0 comments
Closed
Tracked by #3338
Assignees

Comments

@brojd
Copy link
Contributor

brojd commented Nov 13, 2023

Part 1 of using autogenerated types, we should cover here alert groups, integrations and users

Acceptance criteria

  • frontend has additional layer for making HTTP requests
  • every HTTP request goes through this layer (e.g. prevent calling makeRequest directly from components or MobX stores)
  • in this layer every HTTP request and response is typed using types imported from files generated as a part of Improve type-safety: manually generate TS types based OpenAPI schema #3330
  • any other frontend code make use of generated types instead of custom types (e.g. use enum from generated types instead of manual string etc.)

Outcome

  • better type-safety in code
  • being able to catch type errors during development before they reach prod (shift left)
  • better developer experience thanks to increased number of type declarations and improved intellisense
@brojd brojd changed the title Improve type-safety: use autogenerated types across frontend codebase Improve type-safety: use autogenerated types across frontend codebase (part 1) Jan 15, 2024
@brojd brojd self-assigned this Jan 15, 2024
github-merge-queue bot pushed a commit that referenced this issue Feb 20, 2024
# What this PR does

- autogenerate new types exposed by backend, remove custom types that
duplicate autogenerated ones
- use autogenerated types for alert receive channels
- in alert_receive_channel model:
  - use autogenerate http client (`onCallApi`) for http requests
- extract methods that don't update state into
alert_receive_channel.helpers.ts and make them pure (they accept
AlertReceiveChannelStore as param) to avoid inconsistency and issues
with `this` binding
  - use `makeAutoObservable`
  - remove unneeded decorators
- rename update* methods to fetch* whenever such methods retrieve data
from backend with GET requests
- in other models use `@action.bound` for actions and arrow functions
for store methods that are not actions (in subsequent PRs we will apply
the same changes as in alert_receive_channel, this is just for now until
we do it)
- refactor http-client so that it shows global notification on http
errors automatically and provide the possibility to opt-out from it when
making a call
- improve type-safety of `GSelect`
- fix bug related to attaching alert group
(https://raintank-corp.slack.com/archives/C04JCU51NF8/p1707476487580579)

## Which issue(s) this PR fixes

#3331

## Checklist

- [x] Unit, integration, and e2e (if applicable) tests updated
- [x] Documentation added (or `pr:no public docs` PR label added if not
required)
- [x] `CHANGELOG.md` updated (or `pr:no changelog` PR label added if not
required)

---------

Co-authored-by: Vadim Stepanov <vadimkerr@gmail.com>
github-merge-queue bot pushed a commit that referenced this issue Mar 6, 2024
# What this PR does

use autogenerated types for users

## Which issue(s) this PR fixes

#3331

## Checklist

- [x] Unit, integration, and e2e (if applicable) tests updated
- [x] Documentation added (or `pr:no public docs` PR label added if not
required)
- [x] `CHANGELOG.md` updated (or `pr:no changelog` PR label added if not
required)
@brojd brojd closed this as completed Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant