-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Migrate the Post 'Switch to draft' button to ConfirmDialog
component
#37491
Migrate the Post 'Switch to draft' button to ConfirmDialog
component
#37491
Conversation
a989f3d
to
c370f94
Compare
Marking as draft - there's a bug that causes the |
Fixed - state is now handled more effectively, and the confirmation dialog is reset after the cancel button is clicked. |
fc850ec
to
014ba4b
Compare
014ba4b
to
2066a3a
Compare
Updated this PR to simplify the implementation of |
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 @chad1008 , thank you for working on this!
Overall the changes test well according to your instructions! I left a couple of minor comments, but this is definitely looking good!
One more questions — I'm not expert about the editor package, but it may be good to double check if this could affect any unit/e2e tests (although I can't see any failures), or if this interaction would benefit from adding an e2e tests at all (not sure who's better-suited to answer that).
packages/editor/src/components/post-switch-to-draft-button/index.js
Outdated
Show resolved
Hide resolved
Update:
Even with the last comment addressed, I'd still be reluctant to merge this PR until we find a good fix for the |
e2e tests added! I didn't see any existing tests for the switch to draft button so I created new ones. The new tests should cover:
...working out to 16 tests in total, all passing consistent locally. |
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.
Excellent job, @chad1008 ! 🎉
The tests are great — I just wonder if we can write them in a way that tests less the implementation details (classnames, dom structure...) and more the semantics and the way a user would interact with the page (e.g. click a button with a certain text).
I left 2 inline comments specifically to @wordpress/components
classnames — it'd be great if we could refactor the tests.
When we're done with that, we'll be able to merge this PR too!
packages/e2e-tests/specs/editor/various/switch-to-draft.test.js
Outdated
Show resolved
Hide resolved
packages/e2e-tests/specs/editor/various/switch-to-draft.test.js
Outdated
Show resolved
Hide resolved
Thanks for the feedback @ciampo, I'll take a look! This is helpful for me on a more general level... these are both sections of the test I was able to "borrow" from other tests I've worked on recently (i.e. "I need to schedule this post, OH, I know where someone else did that, I'll just reuse that flow!"). After some of your feedback on other PRs, I think I've gotten better about relying on DOM structure when writing my own XPaths/selectors, but I clearly need to apply that same philosophy to code snippets I'm re-using! |
Absolutely! It'd be also great if, once you find a good way to write the e22e tests on this PR, you open another PR to improve the tests you "borrowed" from :) This blog post partially explains the reasoning behind not to test the implementation details (it's focused on React unit testing, but some core principles are the same) |
47dd1bb
to
0fd2339
Compare
I've updated the two class-based XPaths mentioned above, and made a couple other small improvements - there are now no selectors reliant on DOM structure in the test! |
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.
Thank you @chad1008 !
Before merging, it's probably better to double-check that the approach we're taking (ie. avoiding testing implementation details like dom structure, and writing tests more from the point of view of the user) — just cc'ing a few folks who have recently worked in the e2e-tests
package in case they any potential issues cc @aaronrobertshaw @andrewserong @ramonjd @Mamaduka @jorgefilipecosta
@@ -137,6 +135,11 @@ describe( 'Clicking "Switch to draft" on a published post/page', () => { | |||
expect( postStatus ).toBe( 'publish' ); | |||
} ); | |||
it( `should revert a published ${ postType } to a draft if confirmed`, async () => { | |||
// Capitalize postType for use in snackbar XPath | |||
const capitalizedPostType = |
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.
Idea: is there a way in Gutenberg (eg. a utility function) to match text in a case-insensitive way?
In case there isn't, in order to make the test more resilient to capitalisation changes, we could instead:
- convert the expected text
toLowerCase()
- convert the text to be found in the DOM to lower case too, by using the
translate
function
I haven't tried this approach myself, but it could (should) work!
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.
We might also be able to use the lower-case()
or matches()
functions within the XPath selector.
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.
Those are both new to me, thanks for the links @aaronrobertshaw! I wasn't able to implement either, even when testing directly in Chrome's dev tools with strings I know should match it didn't recognize the elements I was targeting. Not sure if it's user error on my part (likely) or something else, but for now I've gone with @ciampo's toLowerCase()
suggestion.
I don't love everything about this implementation... for one thing we're locating the snackbar notification by finding just the word "published" or "reverted" respectively, then pulling the text, lower casing it, and comparing it a full string to my current post type. Feels kind of like taking the long way around, and almost makes me wonder if I shouldn't just stop at identifying a snackbar notif with published/reverted inside it 🤔
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.
Not sure if it's user error on my part (likely) or something else,
Maybe it's related to the version of XPath (it seems like those functions are available from version 2.0)?
I don't love everything about this implementation... for one thing we're locating the snackbar notification by finding just the word "published" or "reverted" respectively, then pulling the text, lower casing it, and comparing it a full string to my current post type. Feels kind of like taking the long way around, and almost makes me wonder if I shouldn't just stop at identifying a snackbar notif with published/reverted inside it 🤔
It does seem convoluted, but I don't know if there's a better way to test for a confirmation that the post was published / reverted. Let's keep it as-is for now, and iterate on it in case we find a better solution!
I just merged the #38524. I will try to have a look on e2e tests later today. |
In general, I'd agree if we can avoid relying on the DOM structure and write them from the user's point of view, we should. In practice, for a lot of e2e tests, I'm not sure how feasible that is. It appears to be pretty common practice in the existing tests to target classes etc. Just because that's the way it was done doesn't mean we should continue that way. I haven't had a chance to properly test this but I did leave one suggestion. If we leverage the |
…ConfirmDialog` component
…og` cancellation
0fd2339
to
cce7fbb
Compare
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 🚀
Thank you @chad1008 for iterating on this and adding e2e tests!
Related: #34153
Description
This PR aims to migrate the post editor's
Switch to draft
button away from the currentconfirm()
implementation and instead use the new experimentalConfirmDialog
component.How has this been tested?
Running WordPress 5.8.2 via
wp-env
:Switch to draft
buttonConfirmDialog
component is rendered instead of the previous browser-based confirmation triggered byconfirm()
Cancel
, and confirm that the post remains publishedSwitch to draft
again, and this time hitOK
. Confirm the post is reverted to a draftI've tested in the latest Chrome, Firefox, and Safari.
Checklist:
*.native.js
files for terms that need renaming or removal).