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
There are several downsides to wrapping XHR, mostly surrounding the large API surface that is required to correctly do it. It would be good for users to have a way to use can-fixture without the XHR shim.
I propose a method that, when called, will check the fixture store first and if it not found, fallback to making a normal HTTP request. I propose something like:
We need to define the shape of that object based on what can-fixture supports. One thing that is unclear to me is if can-fixture is an XHR-only library or if we want to keep it generic enough that fetch could be used instead. If so the shape of the object might need to be more generic to support both.
An adapter could be built for can-connect that uses this method.
The text was updated successfully, but these errors were encountered:
There are several downsides to wrapping XHR, mostly surrounding the large API surface that is required to correctly do it. It would be good for users to have a way to use can-fixture without the XHR shim.
I propose a method that, when called, will check the fixture store first and if it not found, fallback to making a normal HTTP request. I propose something like:
We need to define the shape of that object based on what can-fixture supports. One thing that is unclear to me is if can-fixture is an XHR-only library or if we want to keep it generic enough that
fetch
could be used instead. If so the shape of the object might need to be more generic to support both.An adapter could be built for can-connect that uses this method.
The text was updated successfully, but these errors were encountered: