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

Remove the function that finds posts with upload failure #19353

Merged
merged 1 commit into from
Oct 3, 2022

Conversation

crazytonyli
Copy link
Contributor

The main purpose is further simplifying PostService class. The original function was only used in one place. I removed it since I don't see the need of extract the logic into its own function, considering the function did a very specific, which is finding posts that failed to be saved onto the server and sounds like appropriate to be consolidated into FailedPostsFetcher.

Regression Notes

  1. Potential unintended areas of impact
    None.

  2. What I did to test those areas of impact (or what existing automated tests I relied on)
    None. The new Swift implementation is a direct translation of the original Objective-C implementation.

  3. What automated tests I added (or what prevented me from doing so)
    None.

PR submission checklist:

  • I have completed the Regression Notes.
  • I have considered adding unit tests for my changes.
  • I have considered adding accessibility improvements for my changes.
  • I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

@crazytonyli crazytonyli requested a review from mokagio September 27, 2022 06:05
@crazytonyli crazytonyli self-assigned this Sep 27, 2022
@crazytonyli crazytonyli added the Core Data Issues related to Core Data label Sep 27, 2022
@crazytonyli crazytonyli added this to the 20.9 milestone Sep 27, 2022
@wpmobilebot
Copy link
Contributor

You can test the changes in Jetpack from this Pull Request by:
  • Clicking here or scanning the QR code below to access App Center
  • Then installing the build number pr19353-72ad554 on your iPhone

If you need access to App Center, please ask a maintainer to add you.

@wpmobilebot
Copy link
Contributor

You can test the changes in WordPress from this Pull Request by:
  • Clicking here or scanning the QR code below to access App Center
  • Then installing the build number pr19353-72ad554 on your iPhone

If you need access to App Center, please ask a maintainer to add you.

Copy link
Contributor

@mokagio mokagio left a comment

Choose a reason for hiding this comment

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

Upon reading the description, I thought "well, even if it's used only once, it might still be useful to have the logic isolated to make the code more readable."

After looking at the diff, I agree with your assessment that this narrow logic can suitably live within that method alone.

The only objection that crossed my mind is that it would be nice to have a consistent approach to running queries. I quite like what you have been doing with extracting queries into Active-Record-resembling extensions on model objects. I think it might be beneficial to make that the only way to run queries, so that we have a consistent pattern and abstraction across the codebase. But, that's a broader discussion that would only slow down merging this PR.


init(_ managedObjectContext: NSManagedObjectContext) {
postService = PostService(managedObjectContext: managedObjectContext)
self.managedObjectContext = managedObjectContext
}

func postsAndRetryActions(result: @escaping ([AbstractPost: PostAutoUploadInteractor.AutoUploadAction]) -> Void) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Unrelated to this PR, but I find this name confusing. Do you?

The result parameter is confusing as well. I can see from the type that it's a closure to execute on the results, but upon reading the name I couldn't help but thinking the function itself expected to be passed some kind of result.

I'm also always confused by anything called "result" that is not a Result<Value, Error> type, but that might be my bias towards that lovely type.

Anyway, just wanted to run it past you. I don't have a good suggestion for how to update the code.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Agreed. Something like completion seems like a conventional name. I've seen a couple of other places that use the same variable name.

@mokagio mokagio merged commit 574a195 into trunk Oct 3, 2022
@mokagio mokagio deleted the remove-a-single-usage-function branch October 3, 2022 01:02
@mokagio
Copy link
Contributor

mokagio commented Oct 3, 2022

Took over merging this to ensure it's part of the 20.9 code freeze, which I'll run later today.

@crazytonyli
Copy link
Contributor Author

The only objection that crossed my mind is that it would be nice to have a consistent approach to running queries.

I had actually attempted to build something like this based on this BlogQuery type. But I'm not sure if that's something useful to current code, as I was afraid it became "yet another way to do things". I can clean up what I have on my mac and create a PR, not necessarily to get it merged but to show case what I came up with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core Data Issues related to Core Data
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants