search

backbone-paginator / backbone-pageable

DEPRECATED!!! backbone-pageable and backbone.paginator have merged. Please use backbone-paginator/backbone.paginator instead.
MIT License
343 stars 64 forks source link

A bit tedious to prepare two sets of meta for server mode and infinite mode #149

Closed billychan closed 10 years ago

billychan commented 10 years ago

I used server mode before and am quite happy with it. Today I want to add infinite mode to other models in same project and found that I need to prepare link header in backend.

I'm not saying link header is not good. I just wonder why can't we supply data as well in infinite mode to save unnecessary work when front-end is fully capable of processing such data.

wyuenho commented 10 years ago

Yes you can. Read the readme file. You can override parseLinks if you don't want your server to return a links header.

billychan commented 10 years ago

@wyuenho , thank you for so quick reply. I read the readme and am not very sure what "Facebook Paging object" looks like. Is it the same as "state" object?

wyuenho commented 10 years ago

Well, what's your metadata for server mode look like now?

billychan commented 10 years ago

The current meta format is exactly what server mode need, like

{meta: {totalRecords: 100, sortKey: 'update', ....}, 
data: [{id:1, title: "foo"}, {id:2, title:"bar"}]}

In server mode I use parseState to prepare such data for Pageable collection, like

parseState: (response, queryParams, state, options) ->
  totalRecords: response.meta.total_records
  sortKey     : response.meta.sort_by

I checked the source and found parseLinks method expect return of links, not data. It would be better to allow data as Pageable is able to process it, no need to repeat the work.

wyuenho commented 10 years ago

parseRecords deals with the return of data, not parseLinks. parseLinks is only called for infinite mode to return the metadata needed to fetch the next page. Furthermore, the input for parseLinks is the deserialized resp and options. You can grab your metadata the exact same way as you already do with parseState. You just need to return different metadata from the server or construct your links object on the client side.

billychan commented 10 years ago

Did you mean I still need to prepare the links in server and then ship them in JSON within meta for parsing in parseLinks? I know that but just don't want to repeat such work in server.

wyuenho commented 10 years ago

Make your links object completely on the client side then. total_records should give you enough info to know whether you have more links or not.

billychan commented 10 years ago

@wyuenho , please check if this logic makes sense in infinite mode

Step 1: still parse state to get totalRecords

Given such JSON response

{meta: {totalRecords: 100, sortKey: 'update', ....}, 
data: [{id:1, title: "foo"}, {id:2, title:"bar"}]}

Override parseState in collection

parseState: (resp) ->
  totalRecords = resp.meta.total_records
  sortKey = resp.meta.sortKey
  @links = {}
  @contructLinks()

Step 2: Prepare the links object manually

constructLinks: ->
    @links.next = @getLinks("next")
    #....

This arrangement would totally skip parseLinks in infinite mode. Do you think this makes sense?

wyuenho commented 10 years ago

Only parseLinks will be called under infinite mode. parseState will not be called because there's no state to speak of. This is written down clearly in the API doc and the README.

billychan commented 10 years ago

Okay, I'll prepare the links in server. Thanks for your time.