Do not stringify object rows, skip over them instead

[dextermb]

Currently within the source object/array get stringified. I propose mapping these to null and then filtering columns in render.

Original:

    render() {
        const { row, fields } = this.props;

        return (
            <tr onClick={() => this.handleOnClick(row)}>
                { this.renderCheckboxCell(row.id) }
                { fields.map(field => this.renderCell(field, row)) }
                { this.renderButtons(row) }
            </tr>
        );
    }

    // ...

    renderCell(field, row) {
        let value = row[field.name];

        value = this.props.dataItemManipulator(field.name, value);

        if (typeof value === 'object' || typeof value === 'array') {
            value = JSON.stringify(value);
        }

        return (
            <td key={`${row.id}_${field.name}`}>{ value }</td>
        );
    }

New:

    render() {
        const { row, fields } = this.props;

        return (
            <tr onClick={() => this.handleOnClick(row)}>
                { this.renderCheckboxCell(row.id) }
                { fields.map(field => this.renderCell(field, row)).filter(field => field) }
                { this.renderButtons(row) }
            </tr>
        );
    }

    // ...

    renderCell(field, row) {
        let value = row[field.name];

        value = this.props.dataItemManipulator(field.name, value);

        if (typeof value === 'object' || typeof value === 'array') {
            return null;
        }

        return (
            <td key={`${row.id}_${field.name}`}>{ value }</td>
        );
    }

Thoughts?

[DivineOmega]

Some advantages of the current behaviour is that it is obvious what is present within the field, and makes it easier to implement a DataItemManipulator callback.

A possibly disadvantage @dextermb brought up is that if a relationship is added to a model, its content, which could contain private information, would be immediately rendered in the table.

Ideally, we should output something that makes it obvious the column is not empty, but does not reveal private information. Perhaps we could blank out all values, or replace their content with asterisks, leaving the keys intact, then stringify as is?

[dextermb]

Some advantages of the current behaviour is that it is obvious what is present within the field, and makes it easier to implement a DataItemManipulator callback.

A possibly disadvantage @dextermb brought up is that if a relationship is added to a model, its content, which could contain private information, would be immediately rendered in the table.

Ideally, we should output something that makes it obvious the column is not empty, but does not reveal private information. Perhaps we could blank out all values, or replace their content with asterisks, leaving the keys intact, then stringify as is?

Perhaps we go through and make the values undefined or null. Maybe even <redacted>.

⚠️ Although it is worth mentioning that they would be able to find the data through window.<object> or in the network tab.

[dextermb]

Extra thoughts, @NilesB @JacobBrassington @wheatleyjj @ash123456789

[JacobBrassington]

Shouldn't data that should be redacted never make it to the front end?

[dextermb]

Shouldn't data that should be redacted never make it to the front end?

This issue is, that if someone were to use with on a Laravel model, then the relationship would appear everywhere and magically appear on the frontend.

[DivineOmega]

@JacobBrassington You're very right, it shouldn't. The functionality being discussed is just an extra fail safe to ensure that even if it does somehow reach the frontend, it is not immediately displayed to casual users.