I’m trying to get data refreshed via websockets, using the store to receive the new incoming data. This works well, as it lets various observers be notified of the new data. It seems to be not possible to combine this approach with an initial REST API call that uses a query, as this does not return a RecordArray. The first item in the model FAQ seems to confirm this:
The downside of queries is that they do not live update
Imagine an app that lets you view all data for one customer at a time. In the header of the app, there’s a drop down that lets you choose the current customer you’re viewing. The simple use of that customer ID is as a query param, but that then rules out background refresh of the store via websockets.
One idea I had was a custom REST adapter that always appended a few key params to every request, in my example append a customer ID to the URL. These ‘ambient’ filters might be stored ‘globally’ in a session type object?
There’s another approach I can see where my websocket access is implemented with an entirely custom adapter, that is managing all requests. It either deprecates REST API access entirely, or somehow hits the API method for a first load then schedules websocket updates as well?
Hope that all makes sense, anyone found a way to deal with this type of thing?