DoneJs Supermodel fails to cache extradata coming from API

DoneJS
1

Hi,

Im using the donejs supermodel generator to connect to my API. This is the generated supermodel:

....    
export const documentConnection = superMap({
    	url: '/api/document',
    	idProp: 'id',
    	Map: Document,
    	List: Document.List,
    	name: 'document'
    });
tag('document-model', documentConnection);
export default Document;

And the API is returning the data in the following format:

{
	data: []
	total: 395,
	skip: 0,
	limit: 10
}

Where data holds the rows and total represents the total number of rows before limiting the results. The problem is that sometimes, randomly, total is undefined. Im printing a table with a summary information at the footer indicating the current page and total numbers of rows, with the options to go to the previous or next page. The view:

{{#with documentList.value}}				
<span><i>{{{getPaginationSummary}}}</i></span>
<div class="input-group input-group-sm pull-right" style="width:205px;">
	<div class="input-group-btn">
		<!--<button type="button" class="btn btn-default"><i class="fa fa-fast-backward"></i></button>-->
		<button ($click)="prevPage(skip,limit)" type="button" class="btn btn-default"><i class="fa fa-backward"></i></button>
	</div>
	<input type="text" class="form-control text-center" value="{{{getCurrentPage}}}">
	<div class="input-group-btn">
		<button ($click)="nextPage(skip,limit,total)" type="button" class="btn btn-default"><i class="fa fa-forward"></i></button>
	</div>
</div>
{{/with}}

In the view im calling the function getPaginationSummary, which does the following:

    getPaginationSummary(ctx,tree) {
		let from = parseInt(this.attr('skip')+1);
		let to = parseInt(this.attr('skip')+this.attr('limit'));
		let total = tree._context().attr('total');
		to = (to>total?total:to);
		return "Showing  "+from+" to "+to+" from "+total;
	},

And everything works fine, BUT sometimes randomly, when i hit to an already cached request, for example click on next page and click again to previous page, the value of total is undefined, but the API is always returning this value. So, i took a look to the browser Local Storage at the inspector and i saw all cached queries, but without the extra information like total, skip and limit, just the content of data.

I think this value is undefined because the query is cached and the app is using the cached data set. To test this, i added an extra param called timestamp with the current timestamp on each query, forcing the app to not use the cache. Now total is always defined. But with this “fix” the app is never using the cache.

Another test i did was add the function parseListData to the super model and found out that when the total was undefined the view was rendered before parseListData was executed. I could prove that with simple console.log in the parseListData function and in getPaginationSummary.

Should i create a custom model, with custom behavior to accomplish this instead using the supermodel generator? Please, any help or directions are really appreciated, thanks!!

2

@Gregorio_Godoy Yes, this is a known problem that I’m not totally sure what to do with.

Here’s the issue: https://github.com/canjs/can-connect/issues/129

We’ve added a baseMap module that works like superMap but without the caching: https://github.com/canjs/can-connect/blob/master/can/base-map/base-map.js you can switch to that.

In your example, is total the only thing you’re using that couldn’t be determined from the params / set?

3

@justinbmeyer Thanks for the quick reply!

I think i’ll switch to baseMap because in my case the cache feature is really not critical at the moment, the app is gonna run in a local network. It is an AWESOME feature and for sure i’ll use it in the future.

Yes, total is the only thing i really care about. The API is returning skip and limit too, but i really don’t need them because i already know the values, because im setting them in each request. Im also the API producer, so im considering not returning this values. I think this two values are useful just if they are not set as params in the request, because by default the API returns 10 rows, starting from the first row and you know exactly which range of rows are returned, even if these values were not defined in the query.

Before i read you answer, i was considering to put the total as part of the data set, as a property. Maybe _total or another fixed named that indicates its a metadata. I thing the overhead in the data would be minimal. What do you think about this workaround?

THANKS!!!

4

That work around might work. I’d still like to figure out how to make this work with the fall through cache.