Core Data: Add support for autosaving entities. #16903
Conversation
epiqueras
added
[Package] Core data
epiqueras
requested review from
ajitbohra,
chrisvanpatten,
mkaz,
nerrad and
youknowriad
as code owners
| 'getAutosave', | ||
| persistedRecord.type, | ||
| persistedRecord.id, | ||
| currentUserId |
There was a problem hiding this comment.
Any reason we need the currentUserId to fetch the autosaved post?
There was a problem hiding this comment.
Autosaves are author-specific.
| return acc; | ||
| }, {} ); | ||
| const autosave = yield apiFetch( { | ||
| path: `${ path }/autosaves`, |
There was a problem hiding this comment.
Do you think this is a convention for all entities autosaves? Do we need to check whether a given entity supports autosaves?
There was a problem hiding this comment.
I thought it was. Should it be part of the entity config?
There was a problem hiding this comment.
We can start this way if it's consistent across WP entities, I was just asking.
| ); | ||
| let data = { ...persistedRecord, ...autosavePost, ...record }; | ||
| data = Object.keys( data ).reduce( ( acc, key ) => { | ||
| if ( key in [ 'title', 'excerpt', 'content' ] ) { |
There was a problem hiding this comment.
Is this something to be configured per entity (autosaveable fields or something)
| kind, | ||
| name, | ||
| record, | ||
| { isAutosave = false } = { isAutosave: false } |
There was a problem hiding this comment.
Based on the code changes, it feels that the common code is very small between autosaves and saves, which makes me wonder if they should be two separate action creators.
There was a problem hiding this comment.
I thought that maybe future options could make them share more code.
Should we separate them for now?
There was a problem hiding this comment.
I'm fine either way, you're in a better position to judge as you worked on it :)
| const currentUser = yield select( 'getCurrentUser' ); | ||
| const currentUserId = currentUser ? currentUser.id : undefined; | ||
| const autosavePost = yield select( | ||
| 'getAutosave', |
There was a problem hiding this comment.
Where is this selector defined?
There was a problem hiding this comment.
gutenberg/packages/core-data/src/selectors.js
Line 440 in 9291845
There was a problem hiding this comment.
oh so it was defined before hand? Do you think a user can access autosaves of another user?
There was a problem hiding this comment.
Probably, they are just posts right?
| persistedRecord.id, | ||
| currentUserId | ||
| ); | ||
| let data = { ...persistedRecord, ...autosavePost, ...record }; |
There was a problem hiding this comment.
I'm having trouble understanding which data we're sending. Maybe a comment could help. Like do we send just specific record properties, everything, why are we merging these three records, and why that order.
There was a problem hiding this comment.
I've added this comment:
// Autosaves need all expected fields to be present.
// So we fallback to the previous autosave and then
// to the actual persisted entity if the edits don't
// have a value.
There was a problem hiding this comment.
I guess I'm wondering why we need the three steps merge. If I'm undersanding properly, we don't really need autosavePost here since the edits will most likely contain these as well right?
There was a problem hiding this comment.
Not always.
It has 3 items because we have 2 fallbacks. First, the previous autosave, and then the persisted values.
There was a problem hiding this comment.
Really? The UI only shows the edits and not the autosaved content so I'm having trouble thinking of use-cases where autosaves have more data than edits.
There was a problem hiding this comment.
you would but that's an explicit action. saveEntityRecord( getAutosave() )
There was a problem hiding this comment.
That would not work, you would need to merge the properties like in this PR.
Why complicate things when this will be the only usage of the API. When would you want to clear autosaved properties without changes?
There was a problem hiding this comment.
How does it work today in the editor screen without the refactoring? Say I have an autosave but I ignore it and I continue editing my post, another autosave will trigger right without the updates from the previous autosave?
How would you do that in this new approach?
To be honest, I don't want to complicate anything. I actually think I'm simplifying things. Anyway, I won't block that PR for this, I feel we can tweak this later if needed but still cuirious about the answer to the question above.
There was a problem hiding this comment.
We use this fallback mechanism in the editor store right now.
It works like this right now.
Say I have an autosave but I ignore it and I continue editing my post, another autosave will trigger right without the updates from the previous autosave?
It will have the updates from the previous autosave.
gutenberg/packages/editor/src/store/actions.js
Lines 524 to 528 in 9291845
There was a problem hiding this comment.
It works like this right now.
Ok let's keep it but it feels like a bug to me. cc @adamsilverstein if you know whether an autosave should be created based on the previous autosave or based on the things that are shown in the UI (previous saved state + edits)
* Core Data: Make current offset selector private. * Core Data: Add support for autosaving entities. * Core Data: Clarify why and how autosave payload data is gathered, with a comment.
* Core Data: Make current offset selector private. * Core Data: Add support for autosaving entities. * Core Data: Clarify why and how autosave payload data is gathered, with a comment.
Continues #16867
Description
This PR adds support for autosaving entities in Core Data and makes the recently created "current undo offset" selector private.
How has this been tested?
It has not been tested 😬
Types of Changes
New Feature: Add autosaving support to Core Data entities.
Checklist: