Calling getList on a model with a superMap twice in a row with the same set results in no data for either

1

If I have a simple model that uses superMap like this

import Map from 'can/map/';
import List from 'can/list/';
import superMap from 'can-connect/can/super-map/';
import 'can/map/define/';

let MyModel = Map.extend({ 
  define:{
    someProp: {
      value: ""
    }
  }
});

MyModel.List = List.extend({ Map: MyModel }, { });

MyModel.connection = superMap({
  url: {
    getListData: `GET ${apiBaseUrl}/{someProp}/loadStuff`
  },
  parseListProp: "myStuff",
  idProp: "myId",
  Map: MyModel,
  List: MyModel.List,
  name: 'myModel'
});

export default MyModel;

and data like this

{
 "myStuff":[   
    {   
       "myId":0,
       "name":"name zero"
    },{   
       "myId":1,
       "name":"name one"
    }]
}

When I call getList on MyModel twice in a row with the same set, and that set does not contain any of the same keys as the data, the data is always empty

import MyModel from 'models/my-model';

let listOneDone = new can.Deferred(),
    listTwoDone = new can.Deferred();


let callOne = MyModel.getList({ 
  someProp: 'some-prop-value'
}).then((list) => {
  listOneDone.resolve(list);
});


let callTwo = MyModel.getList({ 
  someProp: 'some-prop-value'
}).then((list) => {
  listTwoDone.resolve(list);
});

can.when(listOneDone, listTwoDone).then((listOne, listTwo) => {
  //listOne.length === 0 && listTwo.length === 0
});
2

Issue here: https://github.com/canjs/can-connect/issues/66

3

Sooooo…

…the problem mentioned above was only kinda the problem. The core of the issue is that can-set is used to merge similar requests (same url & same ajax type) by figuring out what the bigger data set is and pulling out the smaller data set based on how values in the response data line up with the set data. Our client’s api, however, rarely sends much of the request data back in the properties of lists (things such as “userId”, for example, are not present in each item in a list of regions).

One potential way around that would be to ignore properties that are always present in the request data but aren’t in the response list’s items. can-set’s algebra can be used to ignore certain properties in the set that may not be in the response, but that isn’t necessarily a good solution here because there could be situations in which those properties are necessary for combining requests.

The solution we have, now, is to simply not combine requests (by using a custom connection for our region model which doesn’t include the combine-requests behavior).

Potentially, a better solution would be to somehow get the set in parseListData and add the set data onto each item in the list (adding things like “userId”, “countryCode”, etc to each region in the regions list) so that can-set won’t filter those things out… This would require more investigation into superMap’s options and how to use a custom ajax method for getListData (I ran into problems doing this while also superMap – which has the data-url behavior that kept complaining at me).

Better still, it’d be nice if we could simply remove the data from the request that was used to build the url if it isn’t needed any further. I’m much to weary to go down that path, and I think the solution we have now (custom connection without the combine-requests behavior) is sufficient…

Thoughts welcome