You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
those options are passed to the adapter, and inserted as query params. However a supper common use case is to want to trigger a request to
/users/current
However we have no semantic way of differentiating between query params and url options when they are passed in to the adapter. Should we add namespacing to the options object passed in to the query?
We could do the same, with adapterOptions, pagination etc. However, currently all the other adapter methods take a snapshot(remember discussion at https://hackpad.com/RecordArray-Snapshot-JO55bGRbwsn), and will look up the adapterOptions from the snapshot. Should these as well? It is not clear to me that they should as we will never have local data for a query. If they are not
The text was updated successfully, but these errors were encountered:
Currently if you do
those options are passed to the adapter, and inserted as query params. However a supper common use case is to want to trigger a request to
However we have no semantic way of differentiating between query params and url options when they are passed in to the adapter. Should we add namespacing to the options object passed in to the query?
We could do the same, with adapterOptions, pagination etc. However, currently all the other adapter methods take a snapshot(remember discussion at https://hackpad.com/RecordArray-Snapshot-JO55bGRbwsn), and will look up the adapterOptions from the snapshot. Should these as well? It is not clear to me that they should as we will never have local data for a query. If they are not
The text was updated successfully, but these errors were encountered: