Support nested keys with `tableSourceMapper`

[chrispump]

Describe the feature in detail (code, mocks, or screenshots encouraged)

In the table component, we have the option of binding data from our data source to the table via the corresponding keys - we can make use of the utility function tableMapperValues to accomplish this.

Here is an example from the documentation:

const tableSimple: TableSource = {
    // A list of heading labels.
    head: ['Name', 'Symbol', 'Weight'],
    // The data visibly shown in your table body UI.
    body: tableMapperValues(sourceData, ['name', 'symbol', 'weight']),
    // Optional: The data returned when interactive is enabled and a row is clicked.
    meta: tableMapperValues(sourceData, ['position', 'name', 'symbol', 'weight']),
    // Optional: A list of footer labels.
    foot: ['Total', '', '<code class="code">5</code>']
};

tableMapperValues isn't able to work with nested keys like this for example:

tableMapperValues(sourceData, ['id', 'name.first', 'name.last', 'age'])

It would be very useful to support nested keys so that data from more complex structures can also be bound to the table as cell values.

What type of pull request would this be?

Enhancement

Provide relevant links or additional information.

https://www.skeleton.dev/components/tables

[chrispump]

I could make the necessary changes myself and create a pull request if you assign the issue to me.

[endigo9740]

Hey @chrispump, I appreciate the offer, but for Skeleton v3 we're actually considering dropping the <Table> component in favor of just using standard loop iteration for a native HTML tables. This of course would pair with our Table styles (v3 equivalent).

The idea here being that it's a bit more markup on the page, but infinitely more flexible and customizable. This allows for integration with data table solutions like Svelte Simple Datatables, as well as embedding richer content such as HTML and/or components. We may still bring in some kind of utility function for formatting the data, to make it easier to iterate though.

While v2 will continue to exist and be usable to folks, I'd worry this might be extra effort on your part that doesn't carry forward to the majority of users. Honestly it's my recommendation you consider adopting this approach sooner than later. This should be completely possible today.

Let me know if I can help you with this process.

[chrispump]

Hi @endigo9740, yes this seems like a good approach - you're totally right.

As for v2, I just made the change to `tableSourceMapper' and wouldn't see it as an big effort to create a PR. 😁

It's up to you, just let me know. 👍

[endigo9740]

We'll go ahead and table it for now, no pun intended. But keep an eye out for v3's approach. I'll definitely keep this use case in mind. Thanks!