Adapters do not work with custom context.
See original GitHub issueThe fetch adapter supports an option called context
, which allows you to configure where the adapter will look for a fetch object to replace. However, this doesn’t work: updating the context object doesn’t do anything, because the object is a clone.
As a workaround, I’m currently using:
const polly = new Polly(recordingName, {
// ...
adapterOptions: {
fetch: {
context: fetchContext,
}
}
});
fetchContext.fetch = polly.config.adapterOptions.fetch.context.fetch;
Issue Analytics
- State:
- Created 5 years ago
- Comments:5
Top Results From Across the Web
context parameter for custom adapter - getApplicationContext ...
You should pass the context of your activity while creating an adapter object. Application context is different from the activity context ...
Read more >Adapter Registration APIs - zope.component - Read the Docs
An adapter is registered to provide an interface with a name for some number of object types. If a factory implements only one...
Read more >Custom Adapters with RecyclerView
A ViewHolder is an object that stores multiple Views inside the tag field of the Layout so they can be immediately loaded, and...
Read more >Code do not work - how do I create a custom adapter?
I create grid view and in that I try to add image and text but there image is not visible on text is...
Read more >Using Context | CodePath Android Cliffnotes
Whereas an ArrayAdapter requires a context to be passed into it's constructor, a RecyclerView.Adapter does not. Instead, the correct context can be inferred ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thanks for the quick turnaround, everyone!
I wouldn’t bemoan if the library were hard-coded to use the global context. I did end up needing to patch some bugs in
node-fetch
for use in my test environment, so I overrode the globalResponse
andHeaders
classes, but I could just as easily do that if they were on the global object.I should add, I only went down this path because the library advertised it as an option.