Add a 'transform' prop in order to manipulate data before render

[noru]

Hi Rati,

Sorry for the delay. I've tried it with my project. Please take a look and let know if there is anything to change, code style etc. Also, I could update the documentation if it is accepted.

Cheers!

[ratiw]

Thanks @noru. Unfortunately, I thought you weren't comfortable with it, so I've finished it during the weekend for vuetable-2 and will probably port back to vuetable as well within this week. Here's the way I do it.

[noru]

Hi @ratiw , it's great to know that you've chosen to implement it yourself :). Looking forward to vue-table2 as well. It was national holiday in China and I wasn't around at that time, so...

However, your 'transform' doesn't solve my problem. In my project, I'd like to do as such:

transform: (body) =>{
  console.log(body.pagination) // undefined
  let pagination = { /* construct a legal structure for vue-table myself  */ }
  body.pagination = pagination
}

so you see, my problem, particularly, is not about the table data but the pagination. I think your 'dataPath' is sufficient for most cases if not all (does any api serve data as an object instead of an array? that may need more overall of a 'transform')

Some off-topic thinking:

1. A 'transform' in my mind, if not an overall manipulation upon data, would be a row -> row function, and be used like rows.map(transform). Sort of more functional :)
2. I chose props in the end because it is more declarative. And accessing parent namespace, would that be a little intrusive? (I'm new to Vue and still figuring out how to work with it properly)
3. I know vue-table is created based on vue-resource, but, do you plan to support feed table with data instead of Api?
4. Can I inject data other than just 'rowData' for '__component' field? like event handler and so on.

Looking forward to your reply. And if you found any items worth considering, I can create issues for tracking.

Regards

[ratiw]

@noru Sorry for late reply. Extremely busy with other stuffs at the moment.

Does that mean the api you're using does not have the pagination information? Is it possible for you to show me the sample of the data you're getting from the API your code consumed?

I myself do not use a lot of outside API and when I wrote vuetable I try to make it as flexible as I can think of and based most of the work on Laravel and JSON API (jsonapi.org)

In my mind, the transform was meant for data only, but it would be interesting to find and discuss a use case for pagination as well.

About your question regarding the api serving the data as object instead of an array. I don't know if any api has implemented it as such, but I would think it is not the correct way to represent the data. It should be an array, not an object. But, of course, it could be embeded inside an object.

For the off-topic discussion.

1. The data transformation is just an option so that vuetable is useful to others who have no control over the api they're using. It should not be a main feature. The manipulation of data like you mention should be done on the server side in my opinion. vuetable is just a presentation component for the data. vuetable also only deals with a small set of data at any given time but does expect the data to be of the same structure, so transform it only once at the beginning would be much more efficient. The row operation for presenting the data (not transfoming it) is already covered by field callback and component field.
2. At that time, I was looking for a simple way to provide the additional functionality and extensibility and accessing the parent instance seem to be the answer for me. With careful use and knowing what you're doing, it should be pretty safe for that. Passing a function seems pretty nice though.
3. vuetable was created specificly for working with data from the API. Based on my experience, this is the most appropriate way. Feeding the data directly into vuetable or any Vue component will not scale well and cause more problems. But I do have another similar component called vueitems that provide almost the same functionality to vuetable but using an array as the data instead of feeding them from the API. It is much more simple though and aiming for a small list of table in a business form like Quotation, Purchase Order, etc.
4. Nope, you cannot. But I'm curious to know how you would use it.

[noru]

Hi @ratiw, take your time, don't worry :)

About main issue: my API is from AWS cloudsearch. Here's a sample from official document:

{
    "status": {
        "rid": "z67+3L0oHgo6swY=",
        "time-ms": 7
    },
    "hits": {
        "found": 1649,
        "start": 0,
        "cursor": "Vb-HSS4YQW9JSVFKeFpvQ2wwZERBek16SXpOems9Aw",
        "hit": [
            {
                "id": "tt0397892"
            } 
            ...
        ]
    }
}

Despite all that, what essentially need for a pagination component is: skip, top, total (corresponding to the example: start, hit.length, found) and all other numbers are only derivatives. That being said, a server may not return all numbers that vue-table needs (like, current page, last page)

---

Others 1, yeah, I started to realize that may not be a good idea given the nature of front-end development 2, 3, heard and learned 4, my reason is simple, my 'component' field, as a child component of vue-table, have a natural need to communicate with its parents, as normal vue components. Since 'component' is 'injected' by vue-table, this chain is broken here (e.g. props). Although I can fire events as usual but I don't want to abuse the usage.

Cheers!

[ratiw]

@noru I see your point now. But in this case, you will also need to appropriate query back to the API for the next batch of data as well. Do you see the use of append-params sufficient for your use case?

[noru]

@ratiw yes, append-params is enough for me.