-
Notifications
You must be signed in to change notification settings - Fork 16
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
URL Resolver #64
URL Resolver #64
Conversation
- Add initial version URL resolver that passes spec tests
- Add additional validation to URL resolver - Update indicator of Service resolver per spec change - Re-factor Abstract Resolver and Factory to support deprecated indicators - Update tests
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.
Man, this PHP is clean enough that even I can read it. I have a couple of questions, but on the whole it looks awesome.
@@ -53,11 +53,11 @@ public function resolve($definition) | |||
$renderData = []; | |||
|
|||
if ($definition->has('provide')) { | |||
foreach ($definition->get('provide') as $index => $definition) { |
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.
Is this part of the PR functionality or just a little naming cleanup you did along the way?
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.
Yeah, two birds one PR to close #62 as well.
|
||
return $uri->getHost() === self::FAKE_BASE_HOST | ||
? str_replace(self::FAKE_BASE_URL, '', $returnUrl) | ||
: $returnUrl; |
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.
In the spec, these values are supposed to be usable either as strings via coercion, or as objects with URL part properties: https://github.com/magento-research/pwa-studio/tree/develop/packages/upward-spec#urlresolver-example (last line of the section).
Looks like this returns a string. I don't see a test for the property lookup behavior. If it's hard to implement, we could revise the spec to lose that requirement (though I'd prefer it stay in). What do you think?
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.
Not intentional, just an oversight. That seems simple enough, though the return type in upward-js
appears to be a node URL class, or an object with only a subset of those properties. Should I follow that pattern in this implementation?
Refreshed cloud instance with this change to UPWARD and latest copy of Venia. Will run regression tests, and will likely just merge on pass with @dpatil-magento approval. We'll be running a full in depth QA once the resolver is implemented into Venia in scope of #1166. https://master-7rqtwti-xjmpcdjpe6kzm.us-4.magentosite.cloud/ |
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.
👍- - - - - - - - - - 👍👍- - - - 👍👍👍👍- - - -👍 - - - - - 👍
👍- - - - - - - - -👍- - - 👍- - - - - -👍- - - - - - - 👍👍- 👍👍
👍- - - - - - - - -👍- - - - - - - - - - - 👍- - - - - - - 👍- -👍- -👍
👍- - - - - - - - -👍- 👍👍- - - - - -👍- - - - - - - 👍- - - - - -👍
👍👍👍👍- - - - 👍👍- - - - - - -👍- - - - - - - 👍- - - - - -👍
No description provided.