Add data access functions to the table context

[hexagonal-sun]

#168 asks whether the data's table can be obtained for downloading to a user. These sets of patches should allow that to happen by exposing the table's data access functions and field fns to the user.

[aslagle]

Interesting... How are you thinking a user would access these?

[hexagonal-sun]

I don't think there is a API that's exposed once the table has been created (please point me in the right direction if I'm wrong!). For the moment, I'm accessing the data through Template.instance().context.getData{,CSV}. It doesn't seem like the right way to go about it as the context object contains a lot of internal state. I'm not sure how else to go about it though. Any suggestions?

Another alternative is to handle the download request in the package itself and not have to worry about creating an API. I already have a set of patches that adds a 'Download CSV' button to the table using the data accessors in this pr. I didn't push them through just yet, as I wanted feedback on the data functions :).

[aslagle]

Ah I see. Putting these in the data context seems wrong to me too, especially when there are also helpers. There's not a great way to access the helpers either, unfortunately - this is the best I could come up with Template.reactiveTable.__helpers[" sortedRows"].call(Template.instance().context).

The getData function seems fine for client-side only, but allData won't work for server-side collections. For the CSV formatting, I'm not sure how useful it is without more fine-grained control over the columns. A lot of tables will have columns with buttons that should be left out, or columns like dates that are formatted to be human-readable but should be in the original format for download. You'd need a lot of options for configuring it.

As a longer-term solution, I'm planning to try a template helper you can use instead of the template to get the context and an API, and then write more of the template yourself. That would make it easier to add functions like this.

[hexagonal-sun]

Using the helpers doesn't seem like a nice solution either. I've used datatables in the past and they provide an API through jquery once their table has been selected. Maybe we could emulate that as the Handlebars API does provide a jquery selector for templates?

I'll look into the server side of things and see if I can get that working.

I think we would only need to add two options to the fields API to support data exporting: exportable and exportFn. exportable is a boolean that sets whether the column can be exported, this should allow users to have columns that contain buttons and other un-exportable objects. exportFn is a function, very much like fn, that allows the user to serialise their object into a human readable form at export-time. if exportFn is null, we fallback to using the column's fn. If you wish I could code this up and add them to this pr?

[aslagle]

Sure, exportable and exportFn sound good. Not sure if it's better to fall back to the column's fn or the raw value.

I think the main problems are figuring out how to make it accessible and how to make it work with server-side collections, but it will be very useful once those are working. Using jquery to provide the API might be ok - I'd have to see how that would look.

[hexagonal-sun]

If we didn't fall back to fn if exportFn isn't defined, wouldn't that make exporting virtual columns a headache as you'd have to define the same function for fn and exportFn?

I've been looking at using a jquery API and fixing server-side collections, it's looking promising. I'll hopefully have a new PR soon.

[aslagle]

I don't think it's that hard - you could define a variable for the function and use it in both places. I think it would be more annoying to have to define a function for exportFn that just returns the value, if you didn't want to use the same function.

[jangerhofer]

Hello -- just stumbled upon this project. I am looking to export the data visible in the client browser inside a reactive table (to CSV, ideally), but am not quite sure what the code in this commit does. Are you just creating an object containing the table's data?

Can I add on to this commit to stream the table's data to a CSV file? Any pointers are much appreciated. Sorry to intrude!

[mrmowgli]

@hexagonal-sun Any chance you can go a gist on the GUI integration of your CSV patch? About to tackle this too, don't want to reinvent the wheel! :) Definitely a useful addition.