Skip to content
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

Merged
merged 3 commits into from
Apr 29, 2019
Merged

URL Resolver #64

merged 3 commits into from
Apr 29, 2019

Conversation

tjwiebell
Copy link
Contributor

No description provided.

- 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
@tjwiebell tjwiebell requested a review from zetlen April 18, 2019 16:46
Copy link
Contributor

@zetlen zetlen left a 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) {
Copy link
Contributor

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?

Copy link
Contributor Author

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;
Copy link
Contributor

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?

Copy link
Contributor Author

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?

@tjwiebell
Copy link
Contributor Author

tjwiebell commented Apr 29, 2019

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/

Copy link
Contributor

@zetlen zetlen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍- - - - - - - - - - 👍👍- - - - 👍👍👍👍- - - -👍 - - - - - 👍
👍- - - - - - - - -👍- - - 👍- - - - - -👍- - - - - - - 👍👍- 👍👍
👍- - - - - - - - -👍- - - - - - - - - - - 👍- - - - - - - 👍- -👍- -👍
👍- - - - - - - - -👍- 👍👍- - - - - -👍- - - - - - - 👍- - - - - -👍
👍👍👍👍- - - - 👍👍- - - - - - -👍- - - - - - - 👍- - - - - -👍

@dpatil-magento dpatil-magento merged commit b009fbc into develop Apr 29, 2019
@tjwiebell tjwiebell deleted the feature/url-resolver branch December 11, 2019 17:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants