Can you explain a bit more about when generics are needed? Thanks.

@ilyaliao Hi, I added generic for better compatibility with other libraries. In particular, I work with primevue and I take some components (for example, datepicker) as the first argument (modelValue) Date and not string, but format as the second argument, which actually equates Date to string. I understand that this sounds like a primevue problem, but I'm sure that primevue is not the only library that works on a similar principle, so it's easier and more beautiful to add generic to vueuse.&

Making it generic could add some flexibility here, and I don’t think it’d be a breaking change.

maybe I’m missing something. @OrbisK @43081j wdyt?

i'd like to see an example of the usage that lead to this

e.g. you say you bump into it in primevue. can you show us?

formatDate will always return a string, so what case is there where it'd give us something we can type any stronger than that? a string literal type? if so, how?

@43081j Please look at this primevue file. on 519 line you can see that modelValue has type Date | Array<Date> | Array<Date | null> | undefined | null;.
So if i do stuff like:

const localDate = ref<DatePickerProps['modelValue']>(null);
localDate.value = useDateFormat(new Date()); // here will be error Vue: Type ComputedRef<string> is not assignable to type DatePickerProps['modelValue']

<DatePicker
        :model-value="localDate"
      />

the type error is right, though.

useDateFormat resolves to a string, not a Date

you would need to turn it back into a Date or change your value to accept strings

Yes, i undertstand this but i think a code like this
localDate.value = useDateFormat<Date>(new Date());
would look more beautiful.

it would be an error, though:

localDate.value; // Date | Date[]

useDateFormat(new Date()); // string

localDate.value = useDateFormat(new Date()); // type error, we're trying to assign a string to a Date

your change here is to define the return type of useDateFormat. but the return type is always a string, so it doesn't make much sense to pretend it is anything else, in fact that'd cover up errors.

when you write useDateFormat<Date>(val) what do you think Date is being used for? it can't be the return type, because we know this is always a string

I don't think that's what the OP was trying to do though 😬 so it's likely this can be closed once there's understanding why it doesn't make sense to do the change

I don't think that's what the OP was trying to do though

Yes, but with extends string this can still be a good addition to allow fine-tuning of the type, while still not allowing Date as a type.

i dont think we would achieve that through a type parameter

it would be an overload:

function formatDate(date: Date, formatStr: "MMM", options: UseDateFormatOptions = {}): Month;
function formatDate(date: Date, formatStr: string, options: UseDateFormatOptions = {}): string;

but that is way off on a tangent for this PR. we should open a separate PR for that, if we even bother (as the only format you can strongly type is the month name, so doesn't seem worth it).

what this PR exists for and what the OP originally wanted, i think was a misunderstanding. but lets wait for a response

they specifically said useDateFormat<Date>(...) which doesn't make sense, as useDateFormat always returns a string. so this PR doesn't seem to make sense. @Kykydysik can you take a look at my explanation further up and let us know