fall-through-cache is opaque about when the data is finished updating.

[bmomberger-bitovi]

Description:
Using the fall-through-cache behavior in can-connect, MyModel.getList() returns a Promise that resolves to the value from the cache connection (if it exists). Then later, any new items are added. However, there is no indicator that the process has finished. The promise for the server call is swallowed by the fall-through-cache behavior and there is no event fired on the list to indicate it has been updated (or even kept the same).

Here's an example use case where this is not optimal.

• In my view model, I have a list of items (based on a set of filters and a query to the server), and an ID of a user selected item.
• If there is an item selected, it is displayed. If no item is selected, a no-selected-item view is displayed
• On init, or on filter changes, if the selected item is not in the list, then the selected item should be unset. There are one or more filters where the selected item may exist, so changing the query may not necessarily not have the item.
• To do this, I wait until the promise resolves to the current list, then check the IDs of items in the list for the selected ID.
• The out-of-date cache copy of a list doesn't contain the selected item, even though once the server round-trip is complete, it would have that item.
• The result is:
  • my selected item is unselected.
  • The list contains my previously selected item.
  • I am annoyed.

Fall-through-cache connections should do one of the following for getList():

• Attach the promise for the real non-cache connection getList() to the returned List (I prefer this)
• Fire a "connectionComplete" or similar event on the list when the list is fully formed from all sources (less preferred but would also be fine).

Environment:

Software	Version
can-connect version	2.1.0
Browser	All (tested on Chrome 71)
Operating system	All (tested on MacOS 10.14.2)

[justinbmeyer]

I think there might be a pr about this by josh dean. There’s bound to be an issue too.

[justinbmeyer]

#154

[bmomberger-bitovi]

#154 is so out of date that it's not using reflected observability or expando properties. It would require an overhaul to be useful across the board.