Closed NullVoxPopuli closed 1 year ago
I think the path forward here will probably be to use the options
argument for custom cells and pass @options
in your DOM.
that would look like this:
const MyCell = <template>
do something with `@row` or `@data`
</template>
headlessTable({
// ...
columns: () =>
// ...
{
Cell: MyCell,
key: 'foo'
options: (context) => {
return {
your: 'data here',
},
},
}
This already exists, and provides a good semantic escape from built-in rendering intent.
Another option that's possible is to make very custom components for each column / property configuration:
const FooCell = <template>
do something with `@row` or `@data`
</template>
const BarCell = <template>
Access your data is a special way that is relevant to the "bar" property
<FooCell ... />
</template>
headlessTable({
// ...
columns: () =>
// ...
{
Cell: FooCell,
key: 'foo'
},
{
Cell: BarCell,
key: 'bar'
}
in a column config:
the more a person would like to make
MyCell
generic, the more likely it is that they'll want to massage the inputs to that component. Presently, a person would want to have some cached array.map, such as what you could do with: https://ember-resources.pages.dev/funcs/util_map.mapthis is a lot of ceremony (if
value
is not a type fromContentValue
(a renderable type)).I propose a new config option to be added to help with discovery around passing config-driven functions to evaluate to pass to the custom Cell. maybe, the above could be:
and a sample implementation could include something like: