-
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 editor store to thunks #35929
Conversation
Size Change: -32 B (0%) Total Size: 1.14 MB
ℹ️ View Unchanged
|
Looks good from eyeballing and the e2e tests pass. Great work @jsnajdr! React native failure looks suspicious so I restarted it. Even if it's a legit failure, it should be simple to fix. Would you like any help with migrating unit tests? |
e9f0118
to
e4b394c
Compare
e4b394c
to
e309ad8
Compare
I updated (or rewrote 🙂) the unit tests and this migration is now ready for testing, review and shipping. The original tests for actions, especially for the There are two related bugfixes in this PR that are not strictly
|
e309ad8
to
99781b8
Compare
@@ -466,7 +466,7 @@ export const saveEntityRecord = ( | |||
// so the client just sends and receives objects. | |||
const currentUser = select.getCurrentUser(); | |||
const currentUserId = currentUser ? currentUser.id : undefined; | |||
const autosavePost = resolveSelect.getAutosave( | |||
const autosavePost = await resolveSelect.getAutosave( |
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.
How did we miss it? :o great catch!
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 situation we'd need looks like: the post has edits for content, a previous autosave for title, and now we want to do a new autosave. And we want to autosave the full { content, title } tuple because both attributes are changed. But under what circumstances is it possible that the title changes are in autosave but not in local edits?
@jsnajdr Hm perhaps when if the autosave was created in one editing session, then the page was refreshed, and the new editor uses that autosave but without any local edits? On the other hand, if the await
was missing for a few months and noone noticed any difference, maybe we could remove that entirely 🤔 let's get this PR in, research any familiar-looking issues, and try removing that in a follow-up PR
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.
Hm perhaps when if the autosave was created in one editing session, then the page was refreshed, and the new editor uses that autosave but without any local edits?
In that case, when I refresh the page, the editor tells me that there is an existing autosave and asks if I want to apply it? If I don't, it's discarded, if I do, the autosave changes become edits?
if the
await
was missing for a few months and noone noticed any difference, maybe we could remove that entirely
It's also possible that people were actually losing data in a rare edge case, without ever having enough info to report an issue, and that's not a good thing. We should certainly investigate this further.
); | ||
} | ||
*/ | ||
export const editPost = ( edits, options ) => ( { select, registry } ) => { |
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.
this reads so much better now
* | ||
* @return {Object} An action object | ||
*/ | ||
export function __experimentalRequestPostUpdateFinish( options = {} ) { |
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's __experimental so removing should be fine, I didn't find any remaining usages.
@@ -401,10 +307,9 @@ export function createUndoLevel() { | |||
} | |||
|
|||
/** | |||
* Returns an action object used to lock the editor. | |||
* Action that locks the editor. |
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.
How about just
* Action that locks the editor. | |
* Locks the editor. |
without "Action that"?
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 use "Action that ..." quite universally when documenting actions, there are almost 100 usages of that. Therefore I'd rather keep it as is.
*/ | ||
export function* autosave() { | ||
export const autosave = () => () => { |
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.
Is this covered by React Native tests?
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 don't know, I didn't check that. But the change we're doing here looks trivial.
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 does, I was just worrying whether thunks work properly in RN.
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.
Great work! The actions read so much cleaner, the comments do much better job explaining the code, and the tests are more solid this way. On the first sight it may seem like we're testing less, but I believe the opposite is true – this checks the overall store actual behavior vs confirming that a function returns what it says.
Thank you for tackling this one! I left a few comments, but I don't think there's anything blocking (unless we have no RN coverage on the autosave action).
Yeah I totally agree. When writing the new unit tests, I even discovered a bug -- the one with incorrect notice after trashing. |
Draft PR for the purpose of e2e running and @adamziel reviewing 🙂