Post meta: block editor vs. PHP

[janboddez]

Not sure this is the correct place to ask, but if someone can point me to some resource elsewhere, that'd be great too.

So, I need to expose post meta to the block editor.

• A couple values I want to be able to update in the editor, too.
• Another value, however, I want to be able to display but not get overwritten (it is handled by the back end).

I'd read about const [ meta, setMeta ] = wp.coreData.useEntityProp( 'postType', postType, 'meta' ) and so on, so I started using that (for display purposes, at first). And all was well, intially.

Except, changes (to post meta) made on the server -- lets just say I use wp_schedule_single_event() immediately after publishing, to do some API stuff -- are not automagically picked up, i.e., meta does not reflect the latest and greatest status. Don't think it can, to be honest.

Okay, I thought, I'll grab this (updated) metadata from a custom REST endpoint then, no worries.

Except, of course, that if I then update the post or some of its metadata, that the old values overwrite the later ones.

So I tried "unsetting" some of the above meta object's properties, or pass (to setMeta()) a copy of meta with those properties left out. Doesn't seem to be working. Plus, other plugins could obviously still "save" the "original" meta object.

I also tried updating meta with the new values from the server. But what if the (database) value again changes? (Has "Asking for trouble" written all over it.) Plus, some other plugin could obviously still "save" the "original" meta object.

So, how do you deal with this?

Is there a way to register_post_meta() but keep it "read-only"? Using an auth_callback trick? Some JS magic? Or is a custom API endpoint the only way? And should I use register_post_meta() only for anything that is allowed to be edited in the editor? The docs, I'm afraid, could be a little clearer ...

And, is there a way to "better" sync in-editor post meta with whats going on server-side? (The classic editor does not suffer from this nearly as much, as the entire page (including all meta boxes, where you'd typically deal with this stuff) gets reloaded with every change/save.)

[janboddez]

Also, if I replace useEntityProp() with an apiFetch() call, it seems to get run at least once each time an attribute is updated (I've already got it wrapped in useEffect() to not have it continuously call the API).

If I use useEntityProp(), there's only a single set of requests, ever (i.e., while the page/template/etc. is being edited). Which is way less taxing, obviously (but also why the front and back end eventually "get desynced").

Should apiFetch() be the way to get "read-only metadata" working, would there be a way to limit the no. of times it gets called (to just once)?

[janboddez]

Most definitely have to test some more, but I think what I may have been after all this time was register_rest_field() rather than register_post_meta(), and useEntityRecord() (and then select the property we registered) instead of getEntityProp().

getEntityProp() is OK for toggles etc. that you want to be saved 1-on-1 from the editor. If you only want to display data, but not have it become part of the meta property (and subject to being, possibly, overwritten), register_rest_field() looks like it may work.

[janboddez]

register_rest_field() seems to work fine. Meta can be read using the field name of my choice but isn't automatically "saved back" like the meta object is.

Possibly related to the second (less important, because I can poll for background updates, although this where I was struggling with initially) question: #47746