feat: migrate kanban card to script setup #2459
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
3 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/frontend#2459
Loading…
Reference in New Issue
No description provided.
Delete Branch "feature/kanban-card-script-setup"
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?
Hi konrad!
Thank you for creating a PR!
I've deployed the changes of this PR on a preview environment under this URL: https://2459-feature-kanban-card-script-setup--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!
@ -29,3 +29,3 @@
}
export function getHexColor(hexColor: string) {
export function getHexColor(hexColor: string): string {
Asking because I want to learn here:
I don't know the best practise for here: Does this make sense to add here?
Wouldn't the string return type automatically be implied by the returns in the function?
Asking because it feels similar to when you type a variable using
varXY as MyType
which I heared is often a last resort to use, similar to usingany
.I think it would get implied, yes. The reason I added it here was because I added it to the
ITask
interface and that has no way of infering a return type because there's nothing to return.I saw that you added
getHexColor
to the ITask interface.I undid this because:
When we want to use zod later we can't use methods on models. Or at least that's more an antipattern. So I already started to port some methods from models to exported named functions, for example
getAvatarUrl
andgetDisplayName
in the UserModel.I added the method because I wanted to be able to call it in the kanban card where everything was type hinted with the interface only - but the interface did not have the method. If we'll be removing the function from the model anyway I think it's fine to remove it.