Add the refresh_action

[alexandre-castelain]

Add a new action, the RefreshAction, which, as the name suggests, provides a way to refresh the DataTable's content.

This is particularly useful when the data is updated from an external source, and the DataTable serves only as a display.

[Kreyu]

Thanks for the contribution! I am not convinced yet of the use case, especially since it seems that adding a button action with current url would do the same thing, but I've added some questions in the review.

[Kreyu]

I don't think this function is needed, since that identifier is used primarily for the turbo frame. If I call the data_table_name(data_table) I would expect to retrieve its name (data_table.vars.name), without any prefix though

[alexandre-castelain]

I understand, but I don't like the idea of having an identification key that is hard-coded in a view and used in several different places.

Do you have any suggestions on how to change this approach? Perhaps a more explicit function name, such as data_table_turbo_identifier?

[Kreyu]

Do we need this class (and its interface) at all? I think refreshing the data table should always use the current URL, which (I believe) we can retrieve directly in Twig?

[alexandre-castelain]

In our project, we sometimes return the same DataTable in multiple views. To avoid instantiating this DataTable in several places (so as to keep the same options), we created an endpoint that returns only the content of this DataTable.

I wanted to replicate this behavior.

[Kreyu]

Good call 👍🏻 It could be used as row or batch action, but that would be unintuitive.

[alexandre-castelain]

From my point of view, it's not exactly the same.

Firstly, it allows the DataTable to be reused in multiple contexts (potentially across several pages) without needing to know the URL to which it should be redirected. It simply redirects to the current URL, directly taking advantage of Turbo to update its content.

Secondly, redirecting to the page refreshes the entire page. Imagine a page containing four DataTables; all the data would have to be rebuilt again. Currently, given how Turbo works, that’s also the case (unless I’m mistaken). But we could change this behavior.

-> When refreshing a specific DataTable via a query parameter, we could indicate which DT should be refreshed.
-> In that case, within the handleRequest, if it isn’t the correct DT to refresh, don’t fetch the data—and therefore, avoid having to format it. Instead, return an “empty” DT. The complete page view would then contain the refreshed DT with its information and the three others empty. With Turbo refreshing only the frame corresponding to our refreshed DT, we would achieve the expected behavior.
-> Moreover, adding this option to refresh or not via handleRequest could also be used to make DataTables asynchronous. In other words, some tables containing large amounts of data (or simply taking a long time to load) might slow down the display of the entire page. We could add an option that initially doesn’t display any data in the DT, and then, once on the front end, refresh the frame and load ONLY that one DT.

I might be overthinking it, but I sincerely believe this would be an interesting feature to add to the bundle.

What do you think?