You might get prop mutation errors on sortBy and sortDesc due to the listeners on head click that update these values.

You might need local copies of these in data (i.e. localSort and localDesc), and then use the new .sync modifiers on the props, and emit updated:sort-by and update:sort-desc events to update the users copy of the props. And then user watchers on the props to update the local copies.

And then in the _items computed prop, look at the local copies and not the prop versions.

If you like, I can tweak the props/data to handle this.

👍

This works well. You probably don't need to send the field object (as the user probably has a reference to it in their app.

But maybe you could pass field last, as most would probably only need key and the item record data.

Yup, i understand, will remove field param, and check how it will work.

Although it might be handy to have it still in there for some people, but as the 3rd argument.

Yeah, ok, accepted))

Ah, so you are allowing each field to have it's own formatter function (via the fields objects)

I originally thought you were going to have a global field Formatter function (a prop), which would return a format based on the key, item, and field passed to it.

Your solution allows for more flexibility. :)

and what is the option for typeof (field.formatter) === 'string' handle?

I check if supplied value is string or function, to determine if remote formatter is correctly provided.

If provided formatter func declared in global scope and provided as Function to formatter prop, then we directly call it.

So what do these two lines handle?

So, just making a guess... does this allow calling a method defined in the parent (when field.formatter is a string)?

Yep, if formatter supplied as String, then we search for it in parent's methods, this solution have a potential bug, when we have table component in a some wrapper component, like b-table, but i don't find any more flexible solution.

Could a user do this:

{
  data: {
    fields: {
      foo: { sortble: true, formatter this.fooFormatter },
      bar: { sortble: true, formatter this.barFormatter }
    }
  },
  methods: {
    fooFormatter(item, key, field) {
      return item.a + item.b;
    },
    barFormatter(item, key, field) {
      return item.a - item.b;
    },
 }
}

I think the field formatter calling signature should include item, key, field as args.

That way a single formatter function could be used to handle multiple columns, based on the key. That way a user could provide either unique formatters, or a single generic formatter method depending on their preference.

then we must pass these vars from child component.
and this declaration won't work, as parent functions aren't in children's scope. in case we want to use parent's methods, we must supply it as String, Function declaration only for global scoped which will be available to child

data: {
    fields: {
      foo: { sortble: true, formatter this.fooFormatter },
      bar: { sortble: true, formatter this.barFormatter }
    }
  },

the main goal of this is to provide a way to modify single field by simple func... don;t like idea of all-in-one heavy variant

But making the extra args available would make rendering for "virtual" columns (columns that don't have a value in items) be possible (i.e. a virtual column that is comprised of data from different fields within the item record)

Maybe make the formatter function use this signature:

formatter(value, item, key)

And the user can then ignore the extra item, key args if not needed.

Just thinking about adding a bit of flexibility to the formatter functions.

Then we will have two ways of handling table data: slots and formatter callback.
Callbacks will give more reusability, as we can move formatter functions out to standalne module and use it as mixin at components and even as global mixin to app's Vueinstance,
while slots will allow to insert another components into table cell and also format field value and create virtual columns in case we don't need to reuse it at whole app.

Can be used instead of slots, but only for fields that have a real value. Currently one cannot use this for creating data for a virtual column.

Yep, and by design these featues, slots and formatter are mutually exclusive. Ie. if we define formatter at items array, then we cant use slots, and slots are used only if formatter is not defined.

So that should be added to the documentation ;-)