Skip to content

[Gutenberg] Image Size networking (native)#12714

Merged
etoledom merged 21 commits intodevelopfrom
try/gutenberg-image-size-networking-native
Nov 20, 2019
Merged

[Gutenberg] Image Size networking (native)#12714
etoledom merged 21 commits intodevelopfrom
try/gutenberg-image-size-networking-native

Conversation

@etoledom
Copy link
Copy Markdown
Contributor

@etoledom etoledom commented Oct 17, 2019

Alternative to #12706

As a proof of concept, this PR implements the minimum necessary to make Image Size works.
In the future we might need to create a more generic api call with a dynamic request method (given from gutenberg). We also might need to handle other api version Paths.

Related PRs:
gutenberg-mobile: wordpress-mobile/gutenberg-mobile#1455

To test:

Update release notes:

  • I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

@etoledom etoledom force-pushed the try/gutenberg-image-size-networking-native branch from 10e3238 to cf662f2 Compare November 7, 2019 08:00
@peril-wordpress-mobile
Copy link
Copy Markdown

peril-wordpress-mobile bot commented Nov 7, 2019

You can trigger an installable build for these changes by visiting CircleCI here.

@etoledom etoledom marked this pull request as ready for review November 8, 2019 08:53
self.blog = blog
}

func request(response: @escaping Response) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I found quite confusing the response/Response naming for a callback, when the argument to that callback will be the actual response. Maybe we can use the more generic completion?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

sounds good! 👍

}

private var selfHostedPath: String {
let removedEditContext = path.replacingOccurrences(of: "context=edit", with: "context=view")
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Switching the context to view happens to work fine for this specific use case, but it likely won't for others. I don't like the idea of implementing it generically and pretending that apiFetch can now work for anything else, as it might lead to subtle undetected bugs.

Since I understand this is a temporary solution to an immediate problem, I think we should enforce that this system only works with a known set of API paths. So for any request other than getting media sizes, I would probably return a Not implemented error, or ignore the request and just log a warning.

Copy link
Copy Markdown
Contributor

@mchowning mchowning Nov 8, 2019

Choose a reason for hiding this comment

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

I think adding this kind of guard makes sense. Assuming we always expect the platforms to be in sync, it would be nice to have that guard on the JS-side so that we don't have to replicate it on both platforms.

Copy link
Copy Markdown
Contributor Author

@etoledom etoledom Nov 9, 2019

Choose a reason for hiding this comment

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

I thought on having some kind of white list of paths that we accept to avoid surprises.
This implementation also only do GET requests so far, so there's another reason for this. 👍
I agree that is probably better to do this on JS side, then probably this context change should also go on the JS side?

Copy link
Copy Markdown
Contributor

@mchowning mchowning Nov 9, 2019

Choose a reason for hiding this comment

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

I agree that is probably better to do this on JS side, then probably this context change should also go on the JS side?

👍 The more path manipulation we move to the JS side (i.e., the siteId if that's available in JS), the better imo. I was planning to investigate that once I got the Android implementation wrapped up.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

The SiteID is a WPCom thing, probably we don't want it on gutenberg repo.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Good point @etoledom

@@ -0,0 +1,62 @@
import Alamofire

struct GutenbergNetworkRequest {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This is just a bit of a rant, but specially after doing JS for a while, I find interesting how reluctant we all are to use top level functions on Swift. There's no point in rewriting this, but it's something that keeps catching my attention 😁

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I like the Struct to pack some properties inside it, and have methods with less arguments.
At first I did static functions (that would work as well as top level functions), but I didn't like having all the internal helper functions needing the whole set of arguments.

@mchowning
Copy link
Copy Markdown
Contributor

I'm currently seeing an error when try to update the size of an image for a self-hosted site. I'll try to investigate this some tomorrow. I am seeing this show up in the logs, although I don't know whether it is related yet:

2019-11-11 16:35:36.819134-0500 WordPress[15184:4171347] CredStore - performQuery - Error copying matching creds.  Error=-50, query={
    "m_Limit" = "m_LimitAll";
    ptcl = htps;
    srvr = "damp-ducks.jurassic.ninja";
    sync = syna;
}

@mchowning mchowning changed the base branch from develop to gutenberg/release-1.17.0 November 11, 2019 21:51
@mchowning
Copy link
Copy Markdown
Contributor

Hey @etoledom ! I merged gutenberg/release-1.17.0 into this and updated the PR to target that release branch.

mchowning added a commit to wordpress-mobile/gutenberg-mobile that referenced this pull request Nov 15, 2019
Helps to avoid getting unexpected responses and hard to track down bugs:
wordpress-mobile/WordPress-iOS#12714 (comment)
@mchowning mchowning force-pushed the try/gutenberg-image-size-networking-native branch from ee6b8c8 to 67065a0 Compare November 15, 2019 15:47
@etoledom etoledom added Gutenberg Editing and display of Gutenberg blocks. and removed Gutenberg compatibility labels Nov 18, 2019
@etoledom
Copy link
Copy Markdown
Contributor Author

There are a few known issues: wordpress-mobile/gutenberg-mobile#1455 (comment) - I'm hoping those are not blockers for this PR (I'm currently working on those).

Keeping that in mind, I believe this is ready for another 👀
(cc @SergioEstevao @koke )

@etoledom etoledom requested a review from koke November 18, 2019 09:35
@loremattei loremattei modified the milestones: 13.7 ❄️, 13.8 Nov 18, 2019
@loremattei
Copy link
Copy Markdown
Contributor

Hey there! I've moved this to 13.8 since 13.7 has been cut. If you want this to make it to 13.7, please feel free to ping me.

Copy link
Copy Markdown
Contributor

@SergioEstevao SergioEstevao left a comment

Choose a reason for hiding this comment

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

Working fine!

Tested it on WP.com regular, WP.com Atomic and self-hosted sites.

@etoledom etoledom changed the base branch from gutenberg/release-1.17.0 to develop November 19, 2019 07:03
@etoledom etoledom merged commit e0702a4 into develop Nov 20, 2019
@etoledom etoledom deleted the try/gutenberg-image-size-networking-native branch November 20, 2019 09:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Gutenberg Editing and display of Gutenberg blocks.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants