How do I prevent inline-editor from calling the render functions from columnDefs?

How do I prevent inline-editor from calling the render functions from columnDefs?

andrei.ciocanandrei.ciocan Posts: 7Questions: 1Answers: 0

Hello guys, currently I'm facing some performance issues when editing inline, perhaps I'm doing something wrong. I'm using a combination of inline-edit and bubble-edit. I also use multiple custom created fields and tab navigation. Below are the DataTable settings:

 let configObj = {
        rowId: "_id",
        bautoWidth: false,
        pageLength: 100,
        deferRender: true,
        paging: true,
        ajax: {
            url: path,
            type: "GET",
            dataSrc: function (data) {
                if(data && data.data){
                    return data.data;
                } else {
                    return data;
                }
            }
        },
        columns: columns,
        stateSave: true,
        columnDefs: [
            {
                "render": function (data, type, row) {
                    return formatTitleForTable(data);
                },
                targets: title
            },
            {
                "render": function (data, type, row, meta) {
                    return formatDateForTable(data);
                },
                "targets": dates
            },
           ......
}

Inline edit:

 editor.inline(this, {
                    onBlur: "submit",
                    onEsc: 'close',
                    submit: 'changed',
                    drawType: 'none'
                });

Bubble edit:

editor.bubble(this, {
                    submit: 'changed',
                    onEsc: 'close',
                    drawType: 'none'
                });

I'm only submitting changed data, unfortunately each time after submit the render functions from columnDefs trigger multiple times slowing down the editing. Is there any way to prevent this?

Answers

  • colincolin Posts: 15,112Questions: 1Answers: 2,583

    Without seeing the selector that determines the bubble or inline edit, it's hard to say. Are you able to link to your page so we can take a look?

    Colin

  • andrei.ciocanandrei.ciocan Posts: 7Questions: 1Answers: 0

    Hello Colin, I don't think I can link the page but I could probably create a short video containing the information and send it to you in a private message.

  • colincolin Posts: 15,112Questions: 1Answers: 2,583

    A video wouldn't help - we would really need to see the issue. Could you look at this example here and see if you can modify that to demonstrate the problem, please.

    Colin

  • andrei.ciocanandrei.ciocan Posts: 7Questions: 1Answers: 0

    In the example it renders first record 3 times and the first record on the last page 1 time. For me renders all the records, not just the one modified more than 3 times might be the Ajax request getting data dynamically, or something related to keytable, will need to investigate it further, I will post it once I figure out how I can reproduce it.

  • andrei.ciocanandrei.ciocan Posts: 7Questions: 1Answers: 0

    Hmm, if I give more fields as targets and I edit one record the other fields set as targets also re-render.

  • colincolin Posts: 15,112Questions: 1Answers: 2,583

    Sorry, I'm not following. Please update the test case with instructions on how to reproduce and we'll be happy to take a look,

    Colin

  • andrei.ciocanandrei.ciocan Posts: 7Questions: 1Answers: 0

    Try version 4 of the link you just gave me, I've also tried posting a link but it was awaiting for approval and looks like it was not posted.

  • colincolin Posts: 15,112Questions: 1Answers: 2,583

    Thanks for the test case, but as I said, please can you give "instructions on how to reproduce ". I tried that one, inline editing a field about 15 times and I didn't notice any change in performance.

    Colin

  • nicu.spinu@decisionfocus.comnicu.spinu@decisionfocus.com Posts: 1Questions: 0Answers: 0

    @colin - what I experience here, and I believe that's what Andrei tries to describe is the fact that - once you edited one cell - the whole table gets re-rendered(IE: all the columnDefs function get called again).
    Is there any way we can prevent that so that only the edited cell gets re-rendered?
    PS: I don't think you can experience problems with a 100 records table.

  • allanallan Posts: 61,438Questions: 1Answers: 10,052 Site admin

    This is caused by DataTables' orthogonal data support. If you add the type attribute into the console statement, it becomes a bit clearer what is happening. If I edit the first cell in the table I get the following on the console:

    display Airi Satou1
    display Accountant
    type Tiger Nixon
    type System Architect
    sort Airi Satou1
    filter Airi Satou1
    

    First - when you edit a row, the whole row is invalidated, which is why the function is called once for each column in the row (this is to allow for data which is conditional or calculated on the data in another column). The rendering function shouldn't be doing anything more complicated that a calculation or concatenation. If it is doing something like an Ajax request, then that is going to be a major issue.

    Second - the type needs to be calculated each time data is edited in case the edit makes the data in the column This is applied to the table in data index order, which is why it shows up with "Tiger Nixon" there. That can only be a string, so no further checks are required. If it had been a date, then the other data in the column would have been checked. No question - this is one area that DataTables could optimise.

    Third - sorting and filtering must be applied to the new data - hence the final two entries.

    @andrei.ciocan what is your formatTitleForTable function doing?

    Allan

  • andrei.ciocanandrei.ciocan Posts: 7Questions: 1Answers: 0

    Format Title was used to add a preview button to the title, which would open a record. We don't do any ajax requests in render currently, but we mostly had a performance issue due to the amount of data we get at once, for 100 results or lower we wouldn't have any problems. Thank you Allan, now I understand the reasons for multiple renders.

This discussion has been closed.