Is there a way to specify a Vue component inside of the columns declaration?

[ajmcgrail]

Hi there. Big fan of the change that now allows you to use Vue components in named slots, but I had a question/feature request (not sure if it's already implemented). Is there a way to specify a Vue component that will be used WITHOUT using a named slot?

For example, let's say that I want to have a list of button columns that I may or may not want to render, or I want to change the order on them. The point is that using a named slot wouldn't easily allow that. Is there a way to instead pass the Vue component directly in the defined columns of the DataTable component props?

I imagine it would look something like this:

// MyVueComponent is the just the imported vue component
const things: ConfigColumns[] = [{ data: null, render: MyVueComponent, additionalProps: {testProp: 5} }];

But as far as I can tell this isn't supported? I took at look at the DataTable Vue component source code and I think it looks feasible to implement with the existing logic of how Vue components are rendered, along with passing additional props. I might be able to try what I want in a PR if that would be preferred.

Please let me know if I need to give any more information. Thanks for your time!

[AllanJard]

Hi - at the moment no, there isn't the option for that. There are a couple of issues:

1. I never thought of that before :)
2. The component needs to know about the Vue components so it knows when to invalidate them. That might be the biggest stumbling block here. It might require additional information to be passed in.

What's the use case for this over a named slot?

[ajmcgrail]

Hello @AllanJard! I've spent quite a few of the last hours since I opened this issue looking into how to accomplish this and came to the same conclusion you have in point number 2. I do, however, have working code for roughly what I want and can explain it

export function myDataTableButton() {
  //retrieves the current app instance (needs to be called in a .vue file, i placed it here for convenience)
  const instance = getCurrentInstance();
  //base button class for easy extension, the one we use has more stuff in it
  const button = {
    data: null,
    //throws an error about missing a value if this isn't given, though interestingly this is specified in the component slot documentation
    render: () => null,
  };
  button.createdCell = function (cell, _, rowData) {
    //this is how the component is actually rerendered when a dependency changes
    watchEffect(() => {
      //reactive props from outside the function can also be passed and work correctly. things from pinia stores should also work as far as i know
      const component = h(MyComponent, { rowData });
      //passes stuff like global symbols to the newly created component
      component.appContext = instance?.appContext;
      //copied this from your code in the DataTable.vue  component
      render(component, cell);
    });
  };
  return button;
}
const columns = [myDataTableButton()];

Use case of using the above code to create column based Vue components over a named slot:

Arbitrary components can be specified from anywhere. There's no need to use a slot or to hook things up directly in the template logic (which is good if you want to reuse a specific kind of component in a bunch of places or do it programmatically). One issue with using scoped slots that either you can't specify them in a parent of a component (at least easily), and this partially fixes that, or at least it's a way that I know how to do it.

This way also allows Vue refs to be passed to the components in a DataTable column and update reactively. Currently, this does not work when using scoped/named slots for the DataTable component from my testing.

The other benefit is that it's easy to inject the appContext- something that does not currently occur when using the named/scoped slots. For example, we have buttons we'd like to include in arbitrary columns of a DataTable component. We want those buttons to be able to access the vue-router. The vue-router works by using provide/inject (or a similar pattern) that breaks when using DataTable scoped slots. However in the above code, the appContext is supplied to the component and the vue-router works correctly (I don't know if it's reactive, but it seems to work correctly from my testing and demonstrates the point).

To comment on your 2nd point more, that was something I was hoping you might have an answer for. If there was a callback when a cell was destroyed, then at the very least there's a handle on watchEffect to stop it. There's also (probably) a Vue call that can be done to clean up a given component. I honestly don't know if Vue is currently correctly GCing the above example when a component is put into a column.

In terms of how you might include this as a feature, that's where I'm not really sure. I think that you could simply it to just what props/variables are passed to the h() function, but making that be developer/user friendly might be a headache. Even if it always passed cell/type/rowData as a prop to the component, I might want to include my own props on top of that in order to more easily control the component.

If there's anything you'd like clarification on that I said feel free to let me know. In terms of actually achieving the fix for the issue, I'm happy with the code that I came up with, and technically my problem has been answered. That said, I'd be interested in seeing what your thoughts on this might be, and I'm still concerned about GC.

Edit: I have found at least one way to GC and fix the problem. The way you GC something using the vue render() function is by calling render(null, cell). One thing that could be made a lot easier is if there was a callback on each cell that would be called when it was destroyed, because then you could use the following code, and in my testing it actually unmounts/correctly GCs when you call the function:

export function myDataTableButton() {
  //retrieves the current app instance (needs to be called in a .vue file, i placed it here for convenience)
  const instance = getCurrentInstance();
  //base button class for easy extension, the one we use has more stuff in it
  const button = {
    data: null,
    //throws an error about missing a value if this isn't given, though interestingly this is specified in the component slot documentation
    render: () => null,
  };
  button.createdCell = function (cell, _, rowData) {
    //this is how the component is actually rerendered when a dependency changes
    const watcher = watchEffect(() => {
      //reactive props from outside the function can also be passed and work correctly. things from pinia stores should also work as far as i know
      const component = h(MyComponent, { rowData });
      //passes stuff like global symbols to the newly created component
      component.appContext = instance?.appContext;
      //copied this from your code in the DataTable.vue  component
      render(component, cell);
      //would be called when a given cell is destroyed
      button.onDestroy = () => {
        watcher();
        render(null, cell);
      };
    });
  };
  return button;
}

I've investigated even more. My current, incomplete strategy is the following:

Inside the function that creates the Vue components, add the GC function for that vue component to an array.

Upon the unmounting of the DataTable component, call all of these GC functions. It correctly unmounts them and all children of those components.

The problem with this is that it doesn't do it when the page changes. I wanted to do it on the DataTable page event, but there's a problem. If I try to GC the components on the preDraw event, it shows the columns that use the Vue components as empty (as they've been removed) before loading the new components correctly. So that really means I'd need to GC only the components present before the page changes, but GC them AFTER the new page loads (as it's loading through an AJAX call and takes an indeterminate amount of time). Not a hard strategy to implement on a single table, but I don't have an immediate solution for it, as it means I would need to store the draw number with the GC function in order to know if they're safe to remove and somehow pass that to each newly created button.

[AllanJard]

Hi - sorry for the delay in me getting back to you about this!

The appContext seems like the corner stone in this use case. My recent React integration for DataTables allows JSX to be returned in a column definition and I quite liked using that approach. I will have a look at this for Vue as well, although I'm not yet sure of the time scales as I've got a bunch of other stuff planned for development as well.

[ajmcgrail]

Hey there Allan!

I really appreciate the response! Take your time. And I agree that the appContext is very important, I think if that could be set correctly most other things would fall into place, but unfortunately I really wasn't able to find good documentation on how to do that. I don't think what I/you intend to do is a particularly common use case, unfortunately.

[db-hui]

Hi there! Do you plan to revisit this feature? Not having app context available in slots also means other libraries using a provide/inject pattern fail to load properly (e.g. i18n).

Thanks for working on this and publishing example code here!

[AllanJard]

Yes, very definitely plan to come back to this! I'm working on DataTables 3, which is basically taking all of my development time at the moment. I'm desperate to get it wrapped so I can turn to other things (such as improving this component). I'm knee deep in updating the docs at the moment, and then hope to have a beta.

So in short, yes, I absolutely want to come back to this and plan to do so, but I'm not yet certain when. Pull requests welcome!

[db-hui]

Thanks for these insights, looking forward to both DT3 and this feature!

[stanleyxu2005]

@ajmcgrail

I found your approach is smart and very advanced!
You ask display render to do nothing. When a cell is mounted. you create a vnode and mount to the cell.

I previously use manual slots to create a complex DT instance. But I found it will create 2 nested div elements around my cell component. I managed to reduce to 1 with this PR) but it is still not perfect, until I saw your approach.

Below is my simplified version using createdCell:

export function myDataTableCell(columnProps = {}, CellComponent, toCellModel) {
  let defaultContent // can be set to other values, if data can be null, defaultContent must be defined!

  return {
    ...columnProps,

    data: toCellModel,
    defaultContent,

    render: {
      // Display render. if data is defined, set display content to empty string, otherwise default content.
      display: (el) => (el ? '' : defaultContent ), 

      // Other renders for sorting/ordering
      _: (cellData) => cellData ? cellData.getSomeValue() : '',
    },

    createdCell(cell, cellData, rowData, rowIndex, colIndex) {
      // If cellData is defined, create vnode and mount to TD
      const vnodeRequired = cellData && cellData !== defaultContent

      if (vnodeRequired) {
        const vnode = h(CellComponent, { cellData, /* ...other_params */ })

        render(vnode, cell)
        // Code not shown in this example:
        // (1) Register `cell` in a set (slightly different than the official impl of DtVue. I dont use tableId,row,col as key)
        // (2) Once table data is changed, find all `cell` that no longer in DOM and call `render(null, cell)` to trigger vnode unmounting and then remove registered `cell` from the set.
        //   see https://github.com/DataTables/Vue/pull/43
      }
    },
  }
}

I have some questions and suggestions to you and @AllanJard

Point 1: Why you need a watchEffect? Do you really see these vnodes not being recycled?
The original source code, all created host <div> will be deleted when it is not needed. There is no render(null, elements[key]) nor elements[key].remove() and they cannot be, otherwise it will lead to errors.

Point 2: Why you need bind appContext to a component? Is it only very specific to your usage or it is useful in general. I would isolate Cell Component from any global context.

Point 3: I have extra handling for default content. If data is null, without default content, a warning dialog will popup. It's tricky to handle whether vnode is required, if the content is already default content.

Really happy to see this fanatic Vue implementation project and this valuable discussion here.

Best regards
S.X