Add filter for the Preferences modal sections

[Mamaduka]

Description

Introduces new editorPost.PreferencesModal.sections filter. Using this filter, plugin authors will be able to add/remove sections from the "Preferences" modal.

Note: Currently preference modal Section component isn't exported, so I had to copy it for testing. What's the best option to make this available for plugins?

Fixes #28970 and #16401.

How has this been tested?

With custom code that uses this filter.

Custom code

import { addFilter } from '@wordpress/hooks';

const Section = ( { description, title, children } ) => (
	<section className="edit-post-preferences-modal__section">
		<h2 className="edit-post-preferences-modal__section-title">
			{ title }
		</h2>
		{ description && (
			<p className="edit-post-preferences-modal__section-description">
				{ description }
			</p>
		) }
		{ children }
	</section>
);

function addPluginSection( sections ) {
	const pluginSection =
		{
			name: 'plugin-section',
			tabLabel: 'Plugin Section',
			content: (
				<Section title={ 'Plugin Section Title' }>
					<p>Plugin Section Content</p>
				</Section>
			),
		};
	
	// Remove "General" sections for testing purposes.
	const newSections = sections.filter( ( section ) => section.name !== 'general' );

	return [ ...newSections, pluginSection ];
}

addFilter(
	'editorPost.PreferencesModal.sections',
	'mamaduka/addCustomSections',
	addPluginSection
);

Screenshots

Types of changes

New feature

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[Mamaduka]

I've updated the filter name to editorPost.PreferencesModal.sections since it will include all sections, not just core ones.

[gziolo]

I'm all in favor of making the Preferences modal extensible. That's a really great idea. Thank you for starting this PR with the initial proposal.

It feels like we could benefit from creating a more formal API that would be similar to how you work with the custom sidebars using SlotFill as the foundation. There is several plugins available that use the same pattern:
https://github.com/WordPress/gutenberg/tree/trunk/docs/reference-guides/slotfills

Aside from that, the biggest question is whether we want to allow adding extensions only to the Plugins Section tab or whether it should be possible also to add more tabs. Assuming that it's only a single tab to extend, then we should think about more formal ways of defining where the custom components get rendered – each plugin defines in their own section with a label that can contain more granular subsection maybe?

[Mamaduka]

Thanks for the feedback, @gziolo.

I agree that SlotFills as a foundation matches the general pattern used in core better.

This also would be beneficial if we end up extracting editor Preferences to the Interface package (#31965). I assume not all editors would have the same sets of preferences, and they might want to extend it as needed.

/cc @talldan

[talldan]

Yeah, I think a slot/fill makes sense. It's a longer term thing, but it might be good to consider various APIs.

I'm thinking:

• A register function (to handle things like default values)
• Selectors/actions for setting/getting values
• A slot/fill for rendering preferences
• Some user-friendly components to keep the UI consistent (e.g. https://github.com/WordPress/gutenberg/blob/trunk/packages/edit-post/src/components/header/feature-toggle/index.js)

I'm still very early into the work on #31965, but will try to share a draft PR in the next few days. It doesn't have any overlap with this PR, but it will move towards a more generic idea of a preference.

[talldan]

@Mamaduka Here's that draft PR, sorry it took a bit longer than I said it would - #33774

I think the preferences modal could be looked at in a follow-up.

At the moment my plan is to move everything into the interface package, but that might change depending on feedback. Interface does already have some good well defined abstractions for extensibility with its complementary areas and pinned items, so I could see a slot/fill for preferences following a similar pattern.

[Mamaduka]

Thanks, @talldan.

I'll have a closer look next week.