Remove abstract provider #41
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Changed Provider interface to require getConnector method instead of fetch.
Bilge
force-pushed
the
remove-abstract-provider
branch
from
5bb48a0 to
02a8131
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The documentation notes the job of providers is to supply resources with a valid connector, but the interface specified a
fetchmethod, which has little to do with connectors. Now the interface clearly states the intention of the provider removing thefetchmethod and replacing it withgetConnector.This refactor allows us to completely remove
AbstractProviderand boil providers down to a functional interface. This means data is no longer fetched via providers at all; data is fetched directly from resources and providers do nothing more than supply a connector, greatly simplifying the system and removing the burden on implementations to extend an abstract base.Added optional
ProviderOptionsinterface for providers wishing to pass options to resources.TODO: consider passing the resource to
Provider::getConnector. This would allow providers to send different connectors to different resources. Currently no such use case exists but it is conceivable a provider might have multiple APIs with different connectivity requirements so we should probably include support for this. Alternatively we could insist that a provider with multiple APIs should be implemented as multiple providers.