just noting that the logic in this PR is already available in editPost, we can tell it to just load the template directly. so for now, these packages are still equivalent.

They are very different.

This doesn't load @wordpress/editor and all of its unnecessary-for-this-context logic.

Ultimately, it might have to load the editor package because there's a lot of useful components there. Save buttons, Editing Post Title (template title)...

I think you're right when you say, they'll be different it's just not there yet.

The package, yes, but not the provider and/or data flow.

The package, yes, but not the provider and/or data flow.

Why do we need to change the template resolution code in this PR?

Because we need the current template ID saved, and to create template part auto drafts for custom saved templates as well as file ones.

It seems like we're importing the editor package, just to use this component. What does this component do? I'm wondering whether it belongs to the editor package.

It's the entities saving modal. Maybe it belongs in core-data?

It's the entities saving modal

What does it do exactly?

Isn't it the modal that lists entities with unsaved changes and lets the user choose if they want to update them all at once?

Isn't it the modal that lists entities with unsaved changes and lets the user choose if they want to update them all at once?

Yes

Interesting, I guess@editor is the right place though but it makes me think we can reuse more than that from the Editor package (save buttons....) I also thought the components from "editor" had a dependency on EditorProvider. I guess this one is a bit different?

but it makes me think we can reuse more than that from the Editor package (save buttons....)

Not without refactoring them.

I also thought the components from "editor" had a dependency on EditorProvider. I guess this one is a bit different?

Yes

Thinking more here, I feel this component might be misplaced. We could be tempted to update it tomorrow to use the Editor store somehow to enable advanced flows in the editor screen and this will break the Edit Site screen without notice since it's not directly dependent on the editor store aka EditorProvider.

Can we move it to core-data?

Maybe yes, I don't mind if it's done in a separate PR though to think it properly.

What is this line about? Should we comment?
I would have expected something like

$template_id = get_front_page_template();

We need to run the filters so that the template-loader code runs.

How does this prevent us from having a dedicated function that returns the template?

The way we hijack the template hierarchy is by filtering the template getter functions to store the template hierarchy in a global and then filtering template_include to return the template canvas with the found block template. There is no straightforward way to "return" the IDs from there.

This code is doing the same thing the front-end renderer does to set all those things in motion, but instead of echoing the template canvas at the end, it just uses the set globals to get the IDs it needs.

Why underscore?

To avoid shadowing.

I'm replacing this with useEntityBlockEditor in the follow-up PR. Can we ignore it for now?

Do we need to set content (run serialization) on every change? Can't we do something like the editor (use a function edit)

I'm replacing this with useEntityBlockEditor in the follow-up PR. Can we ignore it for now?

Why set the status as soon as we render? It's not clear? should this be done on submit?

It was more natural to write this way and we'll rarely have non-published templates.

We can look at extending EntitiesSavedStates to support additional callbacks.

For me, this is an error. Someone will call our selectors to check the status for this entity and he'll get "published".

Only for the edits selectors.

I don't like that EntitiesSavedStates handle the saving and that this component retrivees the status. It feels like related concerns are separate and most importantly in two separate packages. Not sure how to improve the situation though.

Maybe EntitiesSavedStates should render the button?

Or what do you think of this API?

export default function SaveButton() {
	return (
		<EntitiesSavedStates>
			{ ( { isDirty, isSaving, open } ) => {
				const disabled = ! isDirty || isSaving;
				return (
					<Button
						isPrimary
						aria-disabled={ disabled }
						disabled={ disabled }
						isBusy={ isSaving }
						onClick={ disabled ? undefined : open }
					>
						{ __( 'Update Design' ) }
					</Button>
				);
			} }
		</EntitiesSavedStates>
	);
}

It does seem reasonable but I know we've been talking about rethinking the saving flow (pre/post publish...) regarding FSE so it could have an impact on the API. Maybe we can start as it is right now but not push too far this direction api wise until we're certain of the flows.