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

Only strictly type fetched data after validation #1731

Open
iamacook opened this issue Jul 5, 2024 · 0 comments
Open

Only strictly type fetched data after validation #1731

iamacook opened this issue Jul 5, 2024 · 0 comments

Comments

@iamacook
Copy link
Member

iamacook commented Jul 5, 2024

Description

We currently fetch data and explicitly type the response, validating only on the domain layer. Whilst the layer separation makes sense, we can't be 100% sure that the type matches the response until after validation. Ideally, we should assume the response is unknown until validated.

We should either adjust the types of requests, or validate the response immediately.

Requirements

There are a couple ways to approach this, each adjusting the architecture of the project:

  1. Change reponse types to unknown (or something like T | unknown).

The downside of the above is that the types are "lost" and it is hard to then find the corresponding type. A better suggestion would setting all requests as T | unknown. This is then a) easier as the generic of the service can be changed and not that of every request and b) we always have the relevant type "in place". Validating the response of this will then "remove" then unknown from the union.

  1. Immediately validate responses.

We could "hoist" the validation to the datasource layer. If we want to remain "strict", this does not fit our mental model. However, it means that every call returns the expected type but we generally inject the respective repository though. One thing to note is that we are doing something similar with the "incoming data" of DTOs.

Additional information

No response

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

No branches or pull requests

1 participant