-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Extract the GBK editor parts to a super class #25166
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
base: trunk
Are you sure you want to change the base?
Conversation
|
Generated by 🚫 Danger |
|
| App Name | WordPress | |
| Configuration | Release-Alpha | |
| Build Number | 30596 | |
| Version | PR #25166 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | f452c12 | |
| Installation URL | 6pj1pougqhp4g |
|
| App Name | Jetpack | |
| Configuration | Release-Alpha | |
| Build Number | 30596 | |
| Version | PR #25166 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | f452c12 | |
| Installation URL | 6oqrtgu4e9s48 |
🤖 Build Failure AnalysisThis build has failures. Claude has analyzed them - check the build annotations for details. |
Hey, can you provide a bit of rationale for the change please? What is the problem it solves? Were there alternative options? |
|
@kean Sorry, there is a typo there. I meant to write "PostGBKEditorViewController is |
|
Yes, what's the goal of extracting a superclass? Inheritance, in general, makes code harder to reason about. |
|
@kean My bad. I should have included more context in the PR description. I will implement a new post editor, inheriting from the I don't think it makes sense to add custom post support to the I imagine, in the long run, as we add features to the custom post type support, it will be able to be used to edit regular posts and pages, too. And, by then, we no longer need |
That's a lot of features to re-implement and they all rely on Core Data, just like the rest of the app. |
|
I have not looked into all those features, so I can't say for sure. But I don't imagine we'll write brand-new code to reimplement them for custom posts. We have reused the same UI to add tags (Core Data) and custom terms (the Rust library). That'd be the first thing to explore for the custom post features, too. |
kean
left a comment
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.
The PR looks good. I'm give another pass tomorrow to review the remaining bits.
It makes sense to have a component that provides some defaults on top of GBK's ViewController and have different screens that use them. One more area is the "Comment Editor" that isn't completed yet. I would however suggest considering using composition in NewGutenbergViewController – add GBKEditor on top of it.
kean
left a comment
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.
Hey, I finished the review and added a couple of comments. I assume that the code was moved, so I focused mainly on the overall design.
@dcalhoun, if you also want to weight in, please do.
| self.blog = blog | ||
| self.navigationBarManager = PostEditorNavigationBarManager() | ||
|
|
||
| EditorLocalization.localize = { $0.localized } |
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.
(nit) Should probably bet set once on app launch (existing code)
| } | ||
| } | ||
| /* | ||
| Fix issue: Non-'@objc' instance method 'editorDidLoad' declared in 'PostGBKEditorViewController' cannot be overridden from extension |
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.
You should be able to eliminate this by moving these methods toe the main class declaration outside of the extension.
- seealso: Extract the GBK editor parts to a super class #25166 (review). A cleaner way to implement it would probably be by using composition and providing a separate set of customization points in
GBKViewControllerinstead of overriding a subset of the existingGutenbergKit.EditorViewControllerDelegatemethods.
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 intentionally did not change the API in this PR, because the main purpose are 1) to get rid of the new SimpleGBKEditorViewController in #25157, and 2) minimal changes (in terms of runtime behaviour) to the existing code to make PR easier to review and quick to merge.
In future PRs, I'll start using the new super class in the custom post editor, and make further changes to the API.
| let blog: Blog | ||
| let navigationBarManager: PostEditorNavigationBarManager | ||
|
|
||
| /* private */ let editorViewController: GutenbergKit.EditorViewController |
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.
(nit) Are you planning to address these comment before merging?
| // MARK: - PostEditorNavigationBarManagerDelegate | ||
|
|
||
| var publishButtonText: String { | ||
| wpAssertionFailure("To be implemented by subclasses") |
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.
(nit) This is another area where composition would be probably better/cleaner. I would probably recommend to move PostEditorNavigationBar entirely out of GBKEditorViewController. If we end up using GBKEditorViewController for comments, it won't even use the same navigation bar.
Thanks for the reminder. I plan to review, but it may be next week. No worries if we need to merge before I provide feedback. This is on my list. |





Description
This PR extracts the wiring GBK editor code to a new class
PostGBKEditorViewController, which isnotnow the superclass of the existing NewGutenbergViewController.swift.There is no much actual code changes other than moving them. However, there is one runtime change (the only one that I noticed): the order of function calls in
viewDidLoad: previously,createRevisionOfPostwas the first, but now it's the last. I have examined the implementation, and I don't think this change would cause any practical issues.Note
I highly recommend reviewing this PR commit by commit. You'll see the exact code movement from there.
Testing instructions
Smoke test the GBK editor.