Support Table project

[josevalim]

Hi @djm!

We have a project called Table which provides unified access to tabular data. Maybe it makes sense to support it on TableRex.quick_render!? It is a very tiny project, because it is only meant to act as a protocol. If you support it, you will be able to plot database results, Explorer data frames, Benchee results, and more out of the box.

The only potential conflict is that you assign two different meanings for lists. You always treat lists of enumerables as rows, but Table supports only lists of keyword lists or lists of maps. At the same time, TableRex will print both lists of keyword lists and lists of maps as rows of tuples, which I am not sure it is desired. Table will instead consider the keys as column names.

Therefore you can solve this in three ways, depending on which levels of compatibility you want to keep:

1. Continue rendering lists of maps/keywords as is. This means as soon as you see a list, you keep the current implementation instead of calling Table.to_rows:

   def quick_render!([head | _] = list) do
     # current implementation
   

2. Keep the current implementation only for lists of lists (this means lists of keywords still show tuples as rows but that's understandable) but maps will be printed using keys as columns and values as rows:

   def quick_render!([head | _] = list) when is_list(head) do
     # current implementation
   

3. Change the behaviour for both lists of keywods/maps:

   def quick_render!([head | _] = list) when is_list(head) and not is_tuple(hd(head)) do
     # current implementation
   

Let me know what you think :)

[djm]

Hi José! Just a quick one to say I’ve seen this - I should get some time to read it properly tomorrow. Thanks!

On Wed, 2 Aug 2023 at 10:17, José Valim ***@***.***> wrote: Hi @djm <https://github.com/djm>! We have a project called Table <https://hexdocs.pm/table/Table.html> which provides unified access to tabular data. Maybe it makes sense to support it on TableRex.quick_render!? It is a very tiny project, because it is only meant to act as a protocol. If you support it, you will be able to plot database results, Explorer data frames, Benchee results, and more out of the box. The only potential conflict is that you assign two different meanings for lists. You always treat lists of enumerables as rows, but Table supports only lists of keyword lists or lists of maps. At the same time, TableRex will print both lists of keyword lists and lists of maps as rows of tuples, which I am not sure it is desired. Table will instead consider the keys as column names. Therefore you can solve this in three ways, depending on which levels of compatibility you want to keep: 1. Continue rendering lists of maps/keywords as is. This means as soon as you see a list, you keep the current implementation instead of calling Table.to_rows: def quick_render!([head | _] = list) do current implementation 2. Keep the current implementation only for lists of lists (this means lists of keywords still show tuples as rows but that's understandable) but maps will be printed using keys as columns and values as rows: def quick_render!([head | _] = list) when is_list(head) do current implementation 3. Change the behaviour for both lists of keywods/maps: def quick_render!([head | _] = list) when is_list(head) and not is_tuple(hd(head)) do current implementation Let me know what you think :) — Reply to this email directly, view it on GitHub <#56>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAVVKHIEJIOMGUZSV7PGS3XTILLNANCNFSM6AAAAAA3A633XI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Darian Moody w: djm.org.uk