DataTable UX when using AJAX source

DataTable UX when using AJAX source

ashiremanashireman Posts: 3Questions: 0Answers: 0
edited February 2013 in General
I love DataTables, and have used it in a previous project and knew I would use it in the newer version of this project too. Looking forward to DT2.0...need beta testers? Now that I'm a little more familiar, I'm trying to get at some advanced features and they aren't working the way I have in mind. I had started out with a fairly basic implementation of DataTables. Data is already presented in table format, $('#testTable').datatable() made it spiffy and awesome. While using this static data, I implemented a great way to add/edit/delete rows from the table as needed. All is well and good with the 'static' data source. However, with an AJAX source the experience is not consistent.

What I've run into is my previous AJAX data handling seems to be conflicting with DT's desire to manage itself. Since I've gone through all the work to properly (in my eyes) manage the addData, updateData and deleteRow, I would prefer to use that over how DT wants to reobtain the data, yet still let DT mange the data *only* if it comes through the search filter input. So, let me control add, edit, and delete, but if I search for something within the table, DT can handle requesting the new data.

I think part of the issue is that when I trigger an XHR to, add a row, DT 'senses' the request and, even though I've added the data to the table as part of the beforeSend handler, DT requeries the entire table instead of just waiting to see if the request had a problem. As a side note: In my case it's better to be optimistic in these cases and add/edit/delete the data in the table but be able to revert only if the request fails. Since success is the most likely outcome and this way the user sees the action happen right away instead of waiting for the request to complete, it allows for a good user experience. The issue is similar to both edit and delete where the DT actions don't take place (yet the XHR is successful) and for delete, it doesn't remove from the table at all and with edit, it restores the original content perhaps from some kind of internal cache.

tl;dr

DataTables is awesome.
How can I manually mange rows (adding, editing, deleting) while using an AJAX datasource and only redraw/requery for data if there's input to the table filter? My data management handlers are being overridden/ignored in favor of just requesting all the data again. Is there a combination of bServerSide, bProcessing, sAjaxSource or some kind of event handler function that will accomplish what I'm after?

As an aside, I found a neat feature where taking an existing table with data, and setting bServerSide to false, and setting iDeferLoading loads all the visible data twice. Bug report to follow...soonish.

Replies

  • allanallan Posts: 63,522Questions: 1Answers: 10,473 Site admin
    > Looking forward to DT2.0...need beta testers?

    Probably - in 2015 when I start work on DataTables 2.0...

    > The issue is similar to both edit and delete where the DT actions don't take place (yet the XHR is successful) and for delete, it doesn't remove from the table at all and with edit, it restores the original content perhaps from some kind of internal cache.

    Can you link me to a test case please? You mention server-side processing later on - you can't use fnDeleteRow etc with server-side processing (if you are using server-side processing?) since it is client-side and has no concept of what the data modal is on the server. If you want to delete the data you need to do so at the source and then redraw the table. But it is hard to say without being able to see what you are actually doing.

    > As an aside, I found a neat feature where taking an existing table with data, and setting bServerSide to false, and setting iDeferLoading loads all the visible data twice. Bug report to follow...soonish.

    After you altering the settings in the DataTables settings object dynamically? That is not supported and likely won't ever be. The public API should be used for all alterations to the table and settings, not direct manipulation of the settings object - since DataTables doesn't know that you've changed it and thus can't update other relevant settings.

    Allan
  • ashiremanashireman Posts: 3Questions: 0Answers: 0
    As I found out (but didn't mention I was aware of the limitation), you cannot use fnDeleteRow *and* serverside processing. Even though that's a bummer. You should be able to delete a row client-side, send the appropriate request to the server, and ensure you receive a success message. If something goes wrong, then restore the row. If you have 100 rows visible, why return 100 new rows of data (where 99 are probably the same) from the server? Same with edit, just update the content in that row and ensure you receive a success message.
    http://jsfiddle.net/JjJE2/

    That's about as short and as close as I think I can get it. It's missing some of the actual functions, but they should be named well enough to figure out what they do. Please let me know if I can provide more information.

    For the other issue, I'm trying to make a real fiddle that demonstrates the issue, but jsfiddle can be...difficult enough just to get a marginally complex example to successfully run. But, I'm not updating any setting dynamically. Using basically the same code in the above fiddle, just setting bServerSide with the supplied data should be enough to do it.
    http://jsfiddle.net/qr22V/

    Is 'kinda' like that, but I'm having a hard time getting the correct data to return that DT is expecting.
  • allanallan Posts: 63,522Questions: 1Answers: 10,473 Site admin
    The key thing to remember when using server-side processing is that the data store is at the server, not the client. So when a page needs to be drawn, we need to request all of the data, not just the 1 row that has changed, since the other data might well have changed as well - the data is at the server, so we have no idea if someone else has interest another row, or rows have updated etc.

    Fundamentally that is way all 100 rows need to be returned with server-side processing.

    If you want to just return one row, then use client-side processing, since then DataTables itself is the data store (with server-side processing enabled it is simply an event and display controller - no data handling).

    Regarding your second jsfiddle - I'm not sure I entirely understand what is happening on the page. If ajax loading, with deferred loading enabled, and you've told it there are 10 records in the data set when it is loaded, but there are 57 records in the HTML. At most there should be 10. However, deferred loading of Ajax data was specifically intended for use with server-side processing, not client-side processing where the full data set must be available for DataTables to work.

    Allan
  • ashiremanashireman Posts: 3Questions: 0Answers: 0
    I just wanted to note the differences in User Experience between client-side and server-side processing. Each has their strengths and weaknesses. I'm continuing to work towards a more unified approach where it's possible to have the responsiveness of client-side with the availability of server-side updates.

    I think my ideal is that as changes to a table are submitted, successful transactions are pushed as changesets to all others who are viewing that data. Where push isn't supported, tables can poll the server to see if anything has changed. This way the table is always 'watching' the data source and if changes are made, it only needs to update a small amount of data that's currently visible.

    With the second fiddle, it should have said 57 records and not 10. On my end it was a weird 'trick' where if data was present, and you told Datatables to get data from the server, it would load both into the table resulting in duplicate data. It's not an issue with DataTables, more an issue if it's not configured correctly.

    DataTables is great, thanks for the tips. Keep up the awesome work!
This discussion has been closed.