Feat: add slot for mt-data-table

[quando1910]

What?

Refer this issue: #207

Why?

To have more chances for mt-data-table customization

How?

Just add some slots. Not change any logic.

Testing?

N/A

Screenshots (optional)

N/A

Anything Else?

N/A

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
meteor-component-library	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 4, 2024 1:32pm

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
meteor-admin-sdk-docs	⬜️ Ignored (Inspect)	Visit Preview		Jun 4, 2024 1:32pm

[jleifeld]

I think this can be insecure because this allows also overriding existing renderer. Better would be an approach like this:

<template v-else>
  <!-- Use the correct renderer for the column -->
  <mt-data-table-number-renderer
    v-if="column.renderer === 'number'"
    :data="data"
    :column-definition="column"
    @click="$emit('open-details', data)"
  />

  <mt-data-table-text-renderer
    v-else-if="column.renderer === 'text'"
    :data="data"
    :column-definition="column"
    @click="$emit('open-details', data)"
  />

  <mt-data-table-badge-renderer
    v-else-if="column.renderer === 'badge'"
    :data="data"
    :column-definition="column"
    @click="$emit('open-details', data)"
  />

  <mt-data-table-price-renderer
    v-else-if="column.renderer === 'price'"
    :data="data"
    :column-definition="column"
    @click="$emit('open-details', data)"
  />

  <slot name="custom-column-renderer" :v-bind="{ data, column }"></slot>
</template>

Then it is possible to add new, custom renderer which can be defined in the column definition. E.g.

<template #custom-column-renderer>
    <my-custom-renderer v-if="column.renderer ==== 'my-custom-renderer' />
</template>

[quando1910]

should we use v-else for slot ?

<slot v-else name="custom-column-renderer" v-bind="{ data, column }" />

I updated, please check again

[jleifeld]

Same here. If someone uses this slot some logic with "disableEdit", etc. can get broken by using the slot wrong (e.g. the v-if before does not render the button even if the logic would make sense for it).

I would prefer to implement it in a more safe way with a slot just around the text. Then it is also customizable but is more stable.

<a v-if="!disableEdit" href="#" @click.prevent="$emit('open-details', data)">
  <slot name="action-button" v-bind="{ data }">
    {{ $t("mt-data-table.contextButtons.edit") }}
  </slot>
</a>

[quando1910]

by this way, we can not change the action for this button and can not style for it, for example, I want to replace by a "view details" button instead of the edit button. the case will be we just need another action totally, we don't do anything related to edit features

[jleifeld]

Same here. This would allows to override the context buttons at a whole. I would prefer a property instead of a slot here. Something like this:

additionalContextButtons: {
    type: Array as PropType<Array<{
       // Here the needed information about the buttons
    }>>,
    required: false,
   default: undefined
}

Then we can iterate over this property in the template and can also adjust the v-if check for the context button:

<mt-context-button v-if="!(disableDelete && disableEdit) || additionalContextButtons?.length > 0">

And then do a v-for for all context buttons in the property

[quando1910]

I updated, please check again

[jleifeld]

@Haberkamp I think this implementation could be unstable very quickly. You are more into the topic of filters. Do you have a better, more defined approach for adding custom filter types?

I could imagine a general slot which allows adding custom "filter renderer"

[quando1910]

FYI, the current behavior is not proper with tablet, because it's open a popover, we want to customize the filter button, it will open the modal instead, and our specs requires price filter also, which is not support in popover for now. so we want to custom the button by our own, not reuse the popover logic.