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
Adding basic ordering to tab slot fill #38081
Conversation
abd9c6f
to
ee08a26
Compare
Hi @joshuatf, Apart from reviewing the code changes, please make sure to review the testing instructions as well. You can follow this guide to find out what good testing instructions should look like: |
Test Results SummaryCommit SHA: a082ef4
To view the full API test report, click here. To view the full E2E test report, click here. To view all test reports, visit the WooCommerce Test Reports Dashboard. |
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.
After testing this I notice we lost the default tab selected by default when clicking the left menu item or navigating directly from the url.
Screen.Recording.2023-05-03.at.12.39.17.PM.mov
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.
Experienced the same issue as @mdperez86 and left a couple additional comments.
@@ -371,6 +371,7 @@ public static function register_post_types() { | |||
array( | |||
'id' => 'general', | |||
'title' => __( 'General', 'woocommerce' ), | |||
'order' => 10, |
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.
Just noting that I think this is a good short-term fix, but long-term I'd love to see this order
property removed since this array already determines order and may conflict with the number provided here.
Do we have another issue already to track this long-term and provide a fix for the underlying cause?
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.
@joshuatf Originally I believe both @louwie17 and I were considering this a potential future extensibility point, in which case you'd want a way to control the order by using the slot-fill directly. Now that you mention it, though, that wouldn't ultimately make sense since you'd need to use the block extensibility hooks to relay the inner blocks anyways.
If we're considering this exclusive to internal use then I'd agree that the usage of the order
is just a temporary measure. Louren's created an issue with GB here, but the only feedback so far doesn't consider it a bug. We may want to weigh in there further.
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.
It actually looks like this may have just been resolved upstream.
Edit: I made a note of this in the future concerns doc.
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.
Thanks for updating the future concerns doc, we should check if that does solve our problem, maybe when Gutenberg 15.8
rolls out? As I am not sure how to best build and run Gutenbergs dev version (although I am sure its relatively straightforward).
But the basic ordering may still be needed as this won't be available until the follow WP version.
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 just tested this with the latest GB trunk version and it does seem to be fixed now 🎉
@@ -31,13 +27,6 @@ export function Tabs( { onChange = () => {} }: TabsProps ) { | |||
const [ selected, setSelected ] = useState< string | null >( null ); | |||
const query = getQuery() as Record< string, string >; | |||
|
|||
function onClick( tabId: string ) { | |||
window.document.documentElement.scrollTop = 0; |
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.
Any reason we removed the scroll to top on navigation? I'm no longer being scrolled to the top when navigating to a new tab.
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 removed this line since I noticed that the navigateTo()
utility actually includes that line as well, so it was redundant. On looking at this further I'm realizing that it wasn't working to begin with. This is due to the fact that the form scrolling is actually from the overflow: auto
on the interface-skeleton body, and not the document.
This is actually all seeming a bit odd, as the way it's setup the global sidebar is actually not fixed, but the interface skeleton container is. It's then creating a scrollable body container where our form lives. This could be changed to make the sidebar fixed (as it is with the previous react and legacy editors), but that would be diverging from the blocks way, I suppose. It's also creating the dual scrollbars on the right-hand side of the screen:
We may want to decide first if we want to considering changing anything on a larger scale here to address both of those issues, or work around them. We can't simply use a getScrollContainer()
from @wordpress/dom
here since it's in a slot-fill, but there are other ways to work around it of course.
Perhaps a follow-up then?
Thanks @mdperez86 and @joshuatf for the reviews. I've fixed the issue with the tab not being selected on load in a082ef4, although the other comments are something of a can of worms. We might consider a follow-up for those. |
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.
LGTM @joelclimbsthings nice job!!!
Submission Review Guidelines:
Changes proposed in this Pull Request:
Adding order attribute to tab blocks, and preventing reordering while rendering.
Closes #38002 .
How to test the changes in this Pull Request:
Using the WooCommerce Testing Instructions Guide, include your detailed testing instructions:
product-block-editor
feature flag (can do with WCA Test Helper plugin)