feat: improved types #2547
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#2547
Loading…
Reference in New Issue
No description provided.
Delete Branch "dpschen/frontend:feature/improved-types"
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 is a collection of unrelated type improvements that started growing while I was working on other stuff.
I don't know why my local pnpm always wants to upgrade the pnpm lockfile to 5.4 / why the dependabot lockfile always stays at 5.3. Any idea?
8ce5d0345c
to6888b19cf3
Hi dpschen!
Thank you for creating a PR!
I've deployed the changes of this PR on a preview environment under this URL: https://2547-feature-improved-types--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!
This might be caused by renovate using an outated pnpm version. I've just upgraded renovate so this should be fixed now.
6888b19cf3
toba218180a7
ba218180a7
toa4f24631a9
@ -1,1 +3,4 @@
<!-- just a normal link -->
<!-- a button it shall be -->
<!-- note that we only pass the click listener here -->
<template>
I had to change the way how the BaseButton works for better type support.
It's a bit more repeatition but also very clear now what happens I guess.
Intersting sidenote: I originally placed the comments above inline to the switching elements but the vue renderer had some problems with that. Something about the component being a fragment which it should not be since it has just one root node. But seems like if you add a comment additionally to the root node (in case of a
if / else
that we have here), the comment counts as a node of the component. That makes sense, but is not intuitive, since you normally don't count a comment as content and prevents you from making good comments where they should be :)@ -16,0 +46,4 @@
SUBMIT: 'submit',
} as const
export type BaseButtonTypes = typeof BASE_BUTTON_TYPES_MAP[keyof typeof BASE_BUTTON_TYPES_MAP] | undefined
We export the types in order to use them in inheriting components
@ -53,2 +65,2 @@
rel?: string;
target?: string;
export interface BaseButtonProps extends HTMLAttributes {
type?: BaseButtonTypes
As of now I had to add all possible combinations.
I tried to change the props based on the type but vue wouldn't accept that.
It boils down to that fact that vue currently doesn't support dynamic component types.
It might be that with the latest vue-tsc changes this is possible again.
Stricly speaking right now this component allows impossible prop combinations, these should be validated and filtered. But I hoped that I could spare that effort and solve it instead by establishing common knowledge on how this component is supposed to be used.
I think that's fine. Invalid combinations will show up in PR reviews.
WIP: feat: improved typesto feat: improved types@ -65,2 +46,2 @@
const variantClass = computed(() => BUTTON_TYPES_MAP[props.variant])
// extending the props of the BaseButton
export interface ButtonProps extends BaseButtonProps {
By extending the BaseButtonProps we inherit them and get proper autocomplete! :)
@ -4,3 +2,1 @@
v-bind="elementBindings"
:to="to"
class="dropdown-item">
<BaseButton class="dropdown-item">
By reusing the BaseButton the dropdown-item got much simpler :)
Wow it really looks a lot simpler now.
@ -25,3 +26,3 @@
defineProps({
triggerIcon: {
type: String,
type: String as PropType<IconProp>,
Using
IconProp
enables autocomplete for the icons props@ -14,3 +14,3 @@
v-tooltip="tooltipText"
@click="changeSubscription"
:class="{'is-disabled': disabled}"
:disabled="disabled"
Since dropdown inherits from basebutton it automatically inherits props like disabled
@ -7,3 +7,3 @@
}
if ((typeof date === 'string' || date instanceof String) && !date.startsWith('0001')) {
if ((typeof date === 'string') && !date.startsWith('0001')) {
We should stop using
String()
. Regardless date strings normally come fromtoISOString()
which produces a type stringThere might be cases though where a date string comes from the api and needs to be parsed here. (or at leat that was the reason why I added this function originally)
Unsure if we talk here about the same. I'm talking about the general use of
String()
to convert something to a string. Afaik we don't do that anywhere for the data that's coming from the api. We do use theparseDateOrNull
function but it should would without theinstanceof String
. If you think it should stay, I'm happy to revert this change.@ -21,2 +21,4 @@
updated: Date
settings: IUserSettings
isLocalUser: boolean
Is it correct to add these properties? They seemed to be missing.
yes, that's correct.
@ -28,6 +28,9 @@ export default class UserModel extends AbstractModel<IUser> implements IUser {
updated: Date
settings: IUserSettings
isLocalUser: boolean // FIXME: what should this be
I assumed that the type here is boolean.
That's correct, same as in the interface.
I removed the comment.
@ -19,3 +19,3 @@
},
"vueCompilerOptions": {
"strictTemplates": true
// "strictTemplates": true
Unsure about this
Biggest reason why I can't judge this: Even after the merge of this branch we still have so many type errors that I don't know which errors appear / disappear when I toggle this option.
Is there any difference in the number of errors?
Without
"strictTemplates": true
(I guess the default is false ;) )With
"strictTemplates": true
As said: I do not know which errors these are. It might also be that some disappear while others emerge.
@ -2,2 +7,2 @@
<component
:is="componentNodeName"
<div
v-if="disabled === true && (to !== undefined || href !== undefined)"
Are there any cases where it makes sense for this to be a div?
Yes.
Out of a semantic perspective a disabled button / link is not a button / link.
@ -7,0 +24,4 @@
class="base-button"
rel="noreferrer noopener nofollow"
target="_blank"
ref="button"
This looks like it's missing the
href
attribute.Good catch! Fixed
@ -16,2 +16,2 @@
open.value = !open.value
}
import {ref} from 'vue'
import {onClickOutside} from '@vueuse/core'
I wonder if we even need the helper function I built back in the day?
I already try to remove it piece by piece :)
@ -0,0 +1,40 @@
// copied and slightly modified from unmerged pull request that corrects types
// https://github.com/FortAwesome/vue-fontawesome/pull/355
We need a reminder to remove this once the PR is merged (is that even possible entirely?)
I subscribed to the thread of that PR. So I should get a notification if there are any changes.
Anything blocking this?
Now that the gantt PR is merged there are conflicts :)
I'll do another review but I think we're good.
Looks like the link button does not work :/
(For example when migrating from external services)
d2c153788b
to7f1100e819
I think this was beacause of the missing
href
. Can't reproduce anymore, so should be solved.87511139fe
to781dcb30d6
Can you check again?
781dcb30d6
to480aa8813e