Reduce redundancy with views showing multiple different kinds of tables

dhutton@creativeone.com

We are finding ourselves with several views showing a lot of different datatables and I'm trying to determine if the way we're setting these up is the most efficient. The more views we add the more sets of files we add and they are starting to add up. Right now we have the below:
- Controller - server-side code that handles the httppost and httpget requests per the docs
- Models - determines the data models (POCO)
- Html - we are using razor page and page models but basically the html
- js - each page has a js file associated with it that drives the datatable and its data per the docs

I would love to find an efficient way of creating one set of generic files that can show a datatables data but the solutions we're coming up with are over-engineered and complex. So I'm not sure there's a better way to get these views to display custom data or not.

Building custom queries is straight forward enough, I think we get hung up on the column (and field in the case of editor) definitions for each view. Since each column is explicitly defined in the js is there a way to feed the column definitions to the js from the controller's endpoints? Basically I'd like to take the custom anything and move it to the controller if possible / practical in order to centralize customization logic and reduce the number of extra js and html files that exist. I guess the ideal in my mind is to send a few params to the datatables controller, like what to search for, then the controller or associated class can decide what columns should show, how they render (ie. dates, etc.) and what data each row will contain. I guess I'm trying to componentize datatables so it's just a standard set of files with one place to customize the logic and column / field definitions.

Has anyone tackled something like this before? My immediate use-case is how to show one results page that a user gets to by clicking certain "cards" on their dashboard, showing specific stats. If you click on one of those cards with a particular stat, it takes you to a datatables page that lists the results of that metric without creating a separate html / js (and possibly others) pages for each permutation of metric you offer the users. The differing queries are straight forward enough but I'd like to also be able to define columns outside of the js I guess?

Hopefully that makes sense.

kthorngren

Here is an example of defining dynamically defining columns. Instead of using the Datatables ajax option you would use a jQuery Ajax request then in the success function, for example, you would init you Datatables with the columns variable you parsed and assign the data using data. Doing things like columns.render functions would be very tricky.

Kevin

dhutton@creativeone.com

I think we figured out a way that will work for us and am sharing it in case it helps others. We have 2 js files linked to the html page (razor page), one js file for the page itself (for non-datatable js functionality) and one for the datatable - if that page has a DT anyway. The datatable's js file is in a 'layout' folder that can be reused by multiple pages. Doing it this way keeps all of the settings and customizations for a certain datatable configuration in one file. It does mean any variation to the layout needs a new file and there's redundant js code in each file at times - ie. which columns to show, which columns should render a certain way, etc.

Eventually I'd like to get it set up so the user can define a lot of how their datatable looks and behaves as a user preference but until then I just wanted an easy way to re-use the same datatables configuration across many html pages. We briefly entertained the notion of getting even more granular where certain pieces of the layout (ie. 'dom', pagination vs. lazy loading, etc.) could be managed in multiple files but found that too confusing from a maintenance standpoint so we're going to stick with this. The layout is self-contained in one file and it's pretty straight forward to manage going forward.