-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[behat]Extract Request creation to separate service #13896
Conversation
$builder->withHeader($name, $value); | ||
} | ||
|
||
return $builder->build(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking if we shouldn't return the builder and allow for a build call in the contexts. This would allow for the decoration of this object as well. Perhaps two services would be a good choice? Then we could finalize this service and the default approach to extending it would be with decoration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this idea, but I would rather stick with the current solution for now, and in another PR return Builder. To achieve that I will need to refactor a lot ApiPlatform Client
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could introduce RequestBuilderFactory which will have almost the same API but will return builder, which will be called in factories. But perhaps I'm making it too complex.
e9839a4
to
09ca70a
Compare
d255266
to
77b515e
Compare
public function withHeader(string $name, string $value): self | ||
{ | ||
$this->headers[$name] = $value; | ||
|
||
return $this; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if there would be any benefit of making these calls immutable
public function withHeader(string $name, string $value): self | |
{ | |
$this->headers[$name] = $value; | |
return $this; | |
} | |
public function withHeader(string $name, string $value): self | |
{ | |
$builder = self::create($this->uri, $this->method); | |
$builder->headers[$name] = $value; | |
return $builder; | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking that the builder is kind of mutable pattern (but I might be wrong). Your example implementation will fail with the use case:
$builder
->withHeader('header1', 'value1')
->withHeader('header2', 'value2')
We could change builder implementation like this: (postponed most of the methods)
<?php
final class RequestBuilder
{
private function __construct(
private string $uri,
private string $method,
private array $parameters = [],
private array $headers = [],
private array $content = [],
private array $files = [],
)
{
}
public static function create(string $uri, string $method, /* ... */): self
{
return new self($uri, $method);
}
public function withHeader(string $name, string $value): self
{
$builder = self::create($this->uri, $this->method, $this->parameters, $this->headers /* ... */);
$builder->headers[$name] = $value;
return $builder;
}
public function build(): RequestInterface
{
return new Request(
$this->uri,
$this->method,
$this->parameters,
$this->headers,
$this->content,
$this->files,
);
}
}
But i don't know if this isn't a little bit of overenginnering
$builder->withHeader($name, $value); | ||
} | ||
|
||
return $builder->build(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could introduce RequestBuilderFactory which will have almost the same API but will return builder, which will be called in factories. But perhaps I'm making it too complex.
Thanks, Zbigniew! 🥇 |
…eMilek) This PR was merged into the 1.12 branch. Discussion ---------- | Q | A | |-----------------|--------------------------------------------------------------| | Branch? | 1.12 <!-- see the comment below --> | | Bug fix? | no | | New feature? | no | | BC breaks? | no | | Deprecations? | no <!-- don't forget to update the UPGRADE-*.md file --> | | Related tickets | mentioned in [#Z](#13896) | | License | MIT | <!-- - Bug fixes must be submitted against the 1.11 branch - Features and deprecations must be submitted against the 1.12 branch - Make sure that the correct base branch is set To be sure you are not breaking any Backward Compatibilities, check the documentation: https://docs.sylius.com/en/latest/book/organization/backward-compatibility-promise.html --> Commits ------- 98f4d94 [API][Behat] Add note about behat request changes
It is a part of improving Developer Experience in Behat tests. I removed factory methods out of the Request class, as the object has really grown up. Moved these methods to separate Factory required a lot of changes, that's why I decided to postpone here and merge current changes.
Created Request Builder and Factory will provide an additional layer for future developers to build their own Requests