WIP: feature/zod-schemas #2225
No reviewers
Labels
No Label
area/internal-code
changes requested
confirmed
dependencies
duplicate
good first issue
help wanted
hosting
invalid
kind/bug
kind/feature
question
wontfix
No Milestone
No project
No Assignees
4 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/frontend#2225
Loading…
Reference in New Issue
No description provided.
Delete Branch "dpschen/frontend:feature/zod-schemas"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This builds upon the abstract service ts branch.
First I separated the model types from the models.
Then I experiment a bit with zod.
It seems like using such a tool could help us a lot having good typing everywhere. I think most models can completely be replaced by zod schemas. The few methods that the models have could be helpers that you import on demand.
EDIT: Diff is better visible here: https://kolaente.dev/dpschen/frontend/compare/feature/convert-abstract-service-to-ts...feature/zod-schemas
I have no clue if yup would make more sense to use. Since I don't have experience with these kind of libs I just picked one.
48a83a4fd8
to8cc08582be
8cc08582be
to32b3078ee1
32b3078ee1
tob3ae11e0c3
b3ae11e0c3
to8705ebbe45
8705ebbe45
to4fcd63c8b6
Hi dpschen!
Thank you for creating a PR!
I've deployed the changes of this PR on a preview environment under this URL: https://2225-feature-zod-schemas--vikunja-frontend-preview.netlify.app
You can use this url to view the changes live and test them out.
You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/.
Have a nice day!
4fcd63c8b6
to5198e6b06e
5198e6b06e
to8a5017b2d6
8a5017b2d6
to2c6b7d622a
While we're at it, has an idea of generating schema-like like files from the backend repo been considered?
Yes. But afaik not really possible (at least for zod types) because the current backend provides the API in a non-valid OpenAPI 2 (not 3!).
This let's all generators that I tried fail. Regardless of this we would need to manually improve the types because a 1:1 mapping is not possible. The types defined in this PR could be a good base (but are not fully to date).
Do you have any other idea, or did you have something completely different in mind?
I'll be honest, I have not seen what I suggested in the wild, so I'm not good in the field.
You got some references handy? Issues, forum posts?
See under: https://github.com/colinhacks/zod#ecosystem
#3323 (comment)
2c6b7d622a
toba5c729046