Support PSR HTTP client about google-maps-services-php HOT 15 OPEN

Got it.
It can be a goal, and once it's implemented we can remove Guzzle dependency.

from google-maps-services-php.

Looks like this could be included in #8 right?

from google-maps-services-php.

It looks like in #8, the composer is still using Guzzle.

I think it's inconvenient to maintain a PHP client without a mainstream HTTP client package.

from google-maps-services-php.

@yidas you can still include Guzzle of course, but without forcing other people to use it

from google-maps-services-php.

Hi @garak,

As I know, PSR-18 is the definition of the client interface.
May I know more about how you actually want to achieve?

from google-maps-services-php.

I'd like to use this library without being forced to use Guzzle.
This would also improve the quality of the code, making it more SOLID.

from google-maps-services-php.

Possible with #8 -> instead of the whole client (facade there) just call inner processings

// ...
# today
$calls = new \yidas\googleMaps\Services(new \yidas\googleMaps\Clients\GuzzleClient(), new \yidas\googleMaps\Services\ServiceFactory(new \yidas\googleMaps\ApiAuth($optParams)));
# via PSR
$calls = new \yidas\googleMaps\Services(new \yidas\googleMaps\Clients\PsrClient($yourPsrClient), new \yidas\googleMaps\Services\ServiceFactory(new \yidas\googleMaps\ApiAuth($optParams)));
// ...

from google-maps-services-php.

Not a good idea: dependencies should be injected, not instantiated (again, to be SOLID)

from google-maps-services-php.

I think the main issue remaining is

    "require": {
        ...
        "guzzlehttp/guzzle": "~6.5.6|^7.4.3"
    },

There should be a solution to require the abstract only, not the concrete.
my guess: https://packagist.org/packages/psr/http-client
That's probably what he mainly means.

If we have to major now anyways, with that PR being merged, maybe this is the chance to also clean up that dependency issue

from google-maps-services-php.

@garak : So you just call

class Something
{
    public function __construct(
        protected \yidas\googleMaps\Services $service
    ) {}
}

And set the rest of dependency tree somewhere else... Like in neon config

parameters:
  apiKey: YOUR_API_KEY

services:
  - yidas\googleMaps\ApiAuth(%apiKey%)
  - yidas\googleMaps\Services\ServiceFactory
  - yidas\googleMaps\Clients\PsrClient
  - yidas\googleMaps\Services

I see no problem.

from google-maps-services-php.

@alex-kalanis I was talking about the relationship between \yidas\googleMaps\Services and the HTTP client

from google-maps-services-php.

To which I added context that clarifies it further :)

"require": {
    ...
    "psr/http-client": "^1.0.3"
},

and move guzzle to require-dev for test harness (as default)

from google-maps-services-php.

I'm not sure to understand how it was clarified... the only relevant subject here is the constructor of the class receiving the HTTP client

from google-maps-services-php.

No, also the compose require part as outlined in my previous comment here :) Otherwise you gain nothing really.

from google-maps-services-php.

That can be relevant elsewhere, just not relevant here.

from google-maps-services-php.