editable-columns: forceReloadAfterUpdate - Redraw entire table for some column updates, but not for others.

[tomsb]

I've been working on improving the flexibility of how table updates are handled when certain columns are modified. In some cases, we want to reload the entire table to ensure everything stays consistent. However, for other columns, a full table redraw may not be necessary, and only the updated data needs to be refreshed. To address this, I propose adding a configurable forceReloadAfterUpdate feature.

There could be two ways to set forceReloadAfterUpdate:

protected function setupListOperation()
{
    // Reload after every update:
    CRUD::setOperationSetting('forceReloadAfterUpdate', true);
    
    // Or make a full table reload only if these fields are updated:
    CRUD::setOperationSetting('forceReloadAfterUpdate', [
        'column_name_1',
        'column_name_2',
    ]);
    
    // ...
}

Changes in minor_update_client_logic.blade.php

if (typeof forceReloadAfterUpdate === 'undefined') {
-    var forceReloadAfterUpdate = JSON.parse('{!! json_encode(\CRUD::getOperationSetting('forceReloadAfterUpdate') ?? false) !!}');
+   var forceReloadAfterUpdate = {{ var_export(\CRUD::getOperationSetting('forceReloadAfterUpdate') ?? false) }};
}

// ...

function completeRequest() {
-    if(forceReloadAfterUpdate) {
-        window.crud.table.ajax.reload();
-
-        return;
-    }
+    if(forceReloadAfterUpdate) {
+        if (typeof forceReloadAfterUpdate === 'boolean' && forceReloadAfterUpdate === true){
+            window.crud.table.ajax.reload();
+            return ;
+        }
+
+        if (typeof forceReloadAfterUpdate === 'object'){
+            if (forceReloadAfterUpdate.includes(columnName)){
+                window.crud.table.ajax.reload();
+            }
+        }
+        return;
+    }
    // Re-apply formatting to action column as dropdown
    if (typeof formatActionColumnAsDropdown !== 'undefined' && $('#crudTable').data('has-line-buttons-as-dropdown')) {
        formatActionColumnAsDropdown();
    }
}

// ...

// Update this in three places (in all three AJAX responses):
-   completeRequest();
+  completeRequest(container.dataset.columnName);

Conditional Reloading

A more advanced technique would be to update the forceReloadAfterUpdate variable after each AJAX request, allowing for a more granular approach. For instance, you might want to reload the entire table for column_name_1 under certain conditions but not always. This can be managed through custom response rules/variables in saveMinorUpdateEntry().

Row-Level Updates

Additionally, there could be another option to reload only specific table rows using getMinorUpdateRow(). For example:
Then there could be one more option to reload only specific table rows using getMinorUpdateRow(), for example:

protected function getMinorUpdateRow()
    {
       // ...
-     return CRUD::getEntriesAsJsonForDatatables([$this->minorUpdateEntry->withFakes()], 1, 1)['data'][0] ?? null;
+    $entries = [];
+    $entries[] = $this->minorUpdateEntry->withFakes();
+    $entries[] = $this->minorUpdateEntry->getMuCustomRelatedEntry()->withFakes(); // something like this
+    return CRUD::getEntriesAsJsonForDatatables($entries, count($entries), count($entries))['data'] ?? null;

This option would require a larger update in minor_update_client_logic.blade.php to identify the exact rows that need updating.

• Are there any concerns or suggestions for further refining this approach?
• Does the proposed configuration align well with your use cases?
• Any thoughts on implementing row-level updates?

[backpack-ai-bot[bot]]

Thank you for your detailed question about improving the flexibility of table updates in the editable-columns feature of Backpack. I'll address your proposals based on the information available in the knowledge sources.

1. Configurable forceReloadAfterUpdate feature:
   The idea of adding a configurable forceReloadAfterUpdate feature is not directly mentioned in the provided knowledge sources. However, it aligns with the general flexibility and customization philosophy of Backpack.

2. Changes in minor_update_client_logic.blade.php:
   While the specific file minor_update_client_logic.blade.php is not mentioned in the provided sources, there is a related feature that was added in version 2.1.0 of the Editable Columns add-on. According to the Changelog, an editableColumnsForceTableReload Operation setting was added. This seems to be similar to your proposed forceReloadAfterUpdate feature, although it might not have the granular control you're suggesting.

3. Conditional Reloading:
   The concept of conditional reloading based on specific columns or conditions is not explicitly mentioned in the provided sources. However, it could be a valuable extension of the existing functionality.

4. Row-Level Updates:
   The idea of row-level updates is not directly addressed in the provided knowledge sources. However, it's worth noting that in version 1.0.7 of the Editable Columns add-on, there was a fix for modal fields not being updated after crud table update, which suggests that there have been ongoing improvements to how updates are handled.

Regarding your specific questions:

1. Concerns or suggestions: While your approach seems well-thought-out, it's important to ensure that it doesn't conflict with existing functionality. The editableColumnsForceTableReload setting added in version 2.1.0 might already address some of your needs, so it would be worth investigating how your proposal could build upon or integrate with this existing feature.

2. Alignment with use cases: The flexibility you're proposing would likely be beneficial for many users, as it allows for more fine-grained control over table updates. However, without more specific information about common use cases, it's difficult to say definitively.

3. Row-level updates: This could be a powerful feature, especially for performance optimization in tables with many rows. However, it would require careful implementation to ensure it doesn't introduce new complexities or bugs.

It's worth noting that the Editable Columns add-on has seen regular updates and improvements, as evidenced by the Changelog. Your proposals seem to be in line with the direction of making the feature more flexible and powerful.

For the most up-to-date and specific guidance, I would recommend reaching out to the Backpack community or maintainers directly. They would be best positioned to comment on the feasibility and potential implementation of these features.

Relevant sources:

Editable Columns|2.1.0 28-Nov-2022
Github Issue (closed): Have there any way to refresh the table without lose filters or searches?
Editable Columns|2.0.2 18-Jun-2022
Editable Columns|2.0.7 19-Aug-2022
Editable Columns|2.0.4 20-Jun-2022
Editable Columns|2.0.3 20-Jun-2022
Editable Columns|2.0.0 12-Jun-2022
Editable Columns|1.0.7 10-Jan-2022
Editable Columns|1.0.2 01-Nov-2021
Editable Columns|1.0.1 01-Nov-2021
crud updates
Editable Columns|1.0.4 30-Nov-2021
Editable Columns|1.0.12 10-May-2022
Editable Columns|Editable Columns
Editable Columns|1.0.10 07-Mar-2022

[karandatwani92]

Hey @tomsb

Thanks for your suggestion and efforts. @pxpm, what do you think?

[pxpm]

Thanks @tomsb for the suggestion and for providing the code.

I think the first suggestion is something that can be very useful, I've already created a PR from your code, did a small changes and released editable-columns 3.0.11 that provides this functionality.

Regarding the second one, I am not sure about it, I think it may complicate the code a lot for a small benefit. We already load a limited set of entries in the table, so having more workarounds to just reload row X and Y is cumbersome IMO.

I will be closing this now, please allow a few moments for our private repository to pick the changes and you should be able to get the new version with the changes you proposed.

Nice idea, clean implementation, perfect 👍

Thanks again @tomsb