Allowing a function to take a generic variable

[cursive lion]

Im' not quite sure how to explain my problem but this playground shows the issue - https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAbygUwGYF86qhEcDkAbgK7L4DcAUJTAJ5jJwDyYMwEAdgM4A8AKgD44AXkSU4cTgGFOqYFBAB+AFxwAFABMAhjC0q4fAJQihABRwhgXZD0IRgGgVQnStHAMbJ9a48KF2HKnQqGnpGGQ45BR12DgAlZC5iABt4UQRxOHdZeRBkDVUAIwgIZOQ3IJDkAA9IWCxiDzZOOGJrCKiQGM5+DtzujlMtWmSILUc1TIhWWK5VFmbuXpzoxaGRscdKYwyJbO54AHctYDYOAHMROBRUNVQtZOtDZyzOLnhR8eALq5u7h6eL327zgYGGnw0vzQy0i-TW4M2Ah8IQkZXgAH0UFxSoRkKo1FiUjBVH1VrEEklUr5-PYNCiGk1Yq9YWTOJodFpVHxSV14RtxjtMhIwfyNAA6QgPUhXbS6F4SY6nb7nCVSxiiGBQUj0iQoGDEKAcOAcZCHODmXBWGwIZmdfJFEplNxwdBIgmJHHIaliCS+uCYj3JXFQ7FB5Dyl3PTLoagSLRcWgeBnuRa23I+H2+iHK1XJaUarXhoVwLSK+DTRZcRRi6QrJRitQiiG50hRv1lnOSvPqrAAot+gOh3FqG37O0FOCa6XoNtZzadtVXe6Pfsu2PJ1PuNyeZIZ3a+jsXFs95fWCODz0jtMKe29leRl4xzJ6g1G-cKk5nc4AGmLY9yv5+luHjIMkgG+v+rIcOBqLzhc4HBJQT6hAwBjxgA1lIAAWWhQOcPbvnADiqO8UDKkE1DAvA+6Hj+mSQbysSqAxAAioHIDAyDYbh+HgQxfHbqB4HZvBSFXG0XF1gMI5TBwPKqPGibuOopzICAXIYdxeFeiYmYSAA9PpcDRr+M7kEAA

[serene patio]

@cursive lion Here's a shortened URL of your playground link! You can remove the full link from your message.

mochoman#0

Playground Link

Preview:```ts
import {ref} from "vue"

type Options<T> = {
onConfirm?: (data?: T) => Promise<void>
onCance?: () => void
}

type ConfirmationResult = {
confirmed: boolean
}

export function useConfirmation<TConfirmationPayload>(
options: Options<TConfirmation
...```

You can choose specific lines to embed by selecting them before copying the link.

[cursive lion]

I'm looking to do something similar to react query that allows me to cast my payload to whatever I like (as confirmDeleteCharge is called in my Vue template with the payload)

a payload may or may not be passed in the template, but in this case I know the item: TaskCharge will be there/available

[glad anchor]

If confirm is called before confirmation is called, then you will get undefined in onConfirm, so you need to handle that.

(Btw payload doesn't need to be a ref it can just be a plain JS variable, since you are not returning it from your composable and nothing uses its reactivity)

[cursive lion]

      <template #actions="{ item }">
        <BaseActionMenu>
          <!-- TODO - don't like this icon -->
          <BaseActionMenuItem :icon="Delete" @click="confirmDeleteCharge(item)"
            >Delete</BaseActionMenuItem
          >
        </BaseActionMenu>
      </template>

This is what is in my template.

I get what you are seeing about the confirm being called previously

Maybe I need a better way of handling this composable

    <BaseConfirmDialog
      v-model="waiting"
      :confirm="confirm"
      :cancel="cancel"
      :loading="loading"
      confirm-text="Remove"
      confirm-variant="destroy"
    >
      Are you sure you want to remove this chargre?
    </BaseConfirmDialog>

This dialog doesn't appear until waiting is true, which doesn't happen until await confirmation() essentially. The only way confirm would be called prior to that is if I called it myself

const {
  waiting,
  confirmation: confirmDeleteCharge,
  confirm,
  cancel,
  loading,
} = useConfirmation({
  onConfirm: async (item?: TaskCharge) => {
    if (!item) {
      throw new Error("Charge was not provided");
    }
    await deleteChargeMutation.mutateAsync({ charge: item });
  },
});

Easy fix? ha

[glad anchor]

Yeah you can just do a check and throw/return.

I don't have enough context about what those components are, but it feels odd to me that there are two functions to call for confirming, intuitively it should just be one, so you might want to revisit that and see if you can change your API.

[cursive lion]

Thanks for the feedback. Essentially the first call is to show the dialog (ie. clicking the 'delete' button) and then the confirm call is to actually confirm the deletion

[glad anchor]

Do you always call one right after the other?

[cursive lion]

Pretty much. After calling confirmDeleteCharge, I will either call cancel next (cancel the deletion/hide the dialog) or confirm) which will then call the onConfirm callback

[glad anchor]

Yeah there might be better API design.

Alternatively you can also lift the undefined check to the caller instead, so you aren't doing the same check over and over.

[cursive lion]

Yeah but I guess it could actually be undefined - ie. we aren't actually passing any payload to the confirmation

[glad anchor]

Then you can always use undefined as the generic type.