I don't really understand this one, isn't this a duplicate of syncProperties

You're right, it is partially duplicative! I will update the description to remove the reference to excluded properties.

However, this function is necessary to compute derived properties for the initial load of the persisted entity record (SyncProvider#bootstrap). There is currently only one such example: blocks (derived from content, which is not synced).

Using this example, blocks are not part of the entity record and are not created when the entity is loaded into the store. Instead, core-data provides a hook that parses blocks from content. The block editor uses this hook and then (eventually, maybe) ships back the property as entity record edits.

However, we need to compute and load blocks (once) as part of the bootstrapping process. This ensures that we can correctly reconcile the entity with other peers and / or a persisted CRDT doc.

However, this function is necessary to compute derived properties for the initial load of the persisted entity record (SyncProvider#bootstrap). There is currently only one such example: blocks (derived from content, which is not synced).

This is not just a problem for "sync", the absence of "blocks" on initial fetch is a problem for the whole core-data abstraction. I basically think that we don't have good support/behavior in core data for what we call "transient properties". I had tried to fixed that in the past and add more awareness for these to the framework (see #57500)

I think instead of getInitialObjectData, we should try to bring the idea of #57500 back to life again (having a get/set config for each transient property) at the entities config level but instead of changing how core-data work with these entirely, take a more iterative approach (only use it for sync for now). WDYT?

The concept makes sense and I agree it's sorely needed. I can work it into the PR.

take a more iterative approach (only use it for sync for now).

My interpretation:

1. transientEdits properties can be true (current implementation) or an object with a read function property.
2. The read function is called by the core-data resolver inside the experimental sync flag to materialize the transient properties on the record before passing it to the sync provider.
3. We will forego a write function property for now.
   • I wonder if persist or some other verb would be more appropriate. A write verb implies it is the opposite of read and should/would be called on each entity record edit. But transient properties are not "de-materialized" until the record is persisted. I think I talked myself out of this. :) read is also performed once on entity fetch, so they are in fact opposites.

Let's keep it contained for now and only call these "read/write" where you'd have previously used getInitialObjectData. I think there are other parts of core-data that could benefit from it but we should probably leave that separate as it could be a lot of work to make it right :)

Implemented in 3cef376, with a test in 805e9b2.

I'll confirm @ingeniumed is credited with props for the initial resolver tests.

This is a duplicate of the key property of the entity config, so I don't think it's needed.

Not sure I follow. The entity config defines the properties of an entity type and is shared across all instances of that entity. Most entity configs do not have a key property, including this one.

The "object ID" (as used by the sync provider) is equivalent to the entity record's ID, which is not known until it is loaded into the core-data store via getEntityRecord. This function allows the sync provider to extract the record ID from the entity record it is given. (This function is also not new, it exists in trunk as getSyncObjectId.)

We could instead have core-data actions and resolvers pass in the "object type" (entity kind/name) and "object ID" (record ID). I was following the existing pattern because I thought there was a desire for the entity config to centralize and control sync behavior, including identifiers. Happy to make the change, just let me know.

(I am borrowing the quoted terms from the initial implementation—we can definitely change them as well!)

I thought there was a desire for the entity config to centralize and control sync behavior

Yes, this is the right approach but I think the original implementation was flawed as well in the sense that this configuration already exists in the "entity's config". core-data (without sync) need to know what it's the primary key of each record. It assumes it's id by default unless a key property is specified on the entity config object. In other words, this function is just a duplicate configuration that we can get rid of. (and just pass the full entity config, or augment the "syncConfig" automatically with the "key" property defined in the entity config)

(same for kind/name).

Got it, I'll rework. Thanks for the guidance!

Done in f332ffb

What is this exactly, can't we just use kind/name of the current entity instead?

Yes, see above. This property exists in trunk as syncObjectType and is just carried forward. We could instead require kind / name to be passed in each time a sync provider method is called. Let me know and I'll happily update the code.