mui-datatables: "Deprecated: Passing objects in as data is not supported, and will be prevented in a future release."

Since #1011 is closed, leaving a comment here. I agree that supporting objects for cell data would really create a more flexible and powerful framework.

It is not uncommon for a table cell to include more than just a number or string. For example, having a user avatar that has an image url, name and email is a pretty common use-case. Conceptually, and practically, it makes sense to have this data in one place, instead of some placeholder that will need to be mapped back. Mapping to some external data can be very clunky to implement. It makes sense that a user will want to be able to search any visible data in the table too, but this puts limitations on searching and require accessing an external data source to search the table.

Not having to re-map and restructure the data you need for every render can give some performance benefits as well. If there is some expensive operation, having to only do it once while constructing the table data is much less overhead rather than managing this on every cell re-render.

The concern that the render/search/filter methods could break doesn’t seem very reasonable. All JS objects have a toString method that could be used to avoid breaking. Sure, you will get a poor display, or poor search/filter functionality, but as you said, you're stepping into custom territory and will have to implement more custom logic to support this (cell renderer, recursive search, etc). I’m sure there may even be more elegant solutions to this, but this is extremely low effort.

I really hope this becomes a supported case because this library seems really nice. I am playing with material-table, react-table, and mui-datatables.

mui-datatables appeals to me the most in terms of the features that are enabled out of the box and the overall presentation. But I might have to go with one of the others 😦

Most data passed to the table are grabbed from an API in a json format, which is almost always an array of serialized objects. By removing support for passing objects as data, an overhead is added to the developers so now they need to start modifying their API data for this use case. If the feature is already there and working well, why remove it?

As an FYI, I’ve taken on maintainer responsibilities for this project. I’ve dug into this issue. It stems from this https://github.com/gregnb/mui-datatables/issues/915 issue, which is pretty easy to resolve (though though there are other areas that also need to be touched up to ensure full object support). I think the ability to pass objects is something this library should support, and it clearly is something people find useful. In the next release, this coming Sunday, this restriction will be removed.

I’ll also be introducing a customBodyRenderLite method which will be passed the dataIndex. This method will have better performance over the customBodyRender, though if you’re interested in the details you can check out the release notes when they go up.

@omacranger Be careful with using rowIndex to access the full row data. It breaks when you sort. As @gabrielliwerant said accessing original row data this way requires a dataIndex parameter which I believe is not implemented yet.

The best way to remedy this right now is to do a search for your row data using an id or a key, which is an expensive operation. The search operation being expensive is one of the reasons I believe having direct access to the original data is the best way to go about it.

1. You mean like a fixed column? I think something like that could be useful. Alternatively, a “droppable” option could be added that would just mean columns that are dragged can’t replace that column (and it would function the way you describe). I’d need this to think a little more about this though.
2. I could see it being useful, though it could be done with a helper function that converted the index array to a name array.

Agreeing with the above individuals that passing the value of the current index from the data prop at the top level table into customBodyRender would be a great way to give us access to data without having to do filter / find / parsing indexes ourselves - especially since the table is already accessing that data. Example below of use case. posts array below is the same data that’s being passed into the data attribute on the table itself.

Current method:

customBodyRender: (value, {rowIndex}) => {
    const post = posts[rowIndex];

    return (
        <Button
            component={Link}
            variant="outlined"
            size="small"
            to={{
                pathname: `/posts/${post.id}`,
            }}
        >
            View Post
        </Button>
    )
},

Preferred method:

customBodyRender: (value, {actualFullRowData}) => (
    <Button
        component={Link}
        variant="outlined"
        size="small"
        to={{
            pathname: `/posts/${actualFullRowData.id}`,
        }}
    >
        View Post
    </Button>
),