Plugin sorting via priority property in registerPlugin

[ryanwelcher]

Description

As is stands now, there is no way to control the order of the items being rendered in Slots. This PR adds a new priority property to the settings object that is passed to registerPlugin. This property is optional and has a default value of 10. I chose 10 as that is the default priority for Hooks and familiar to most WordPress developers and so that we can move items ahead of the default position without using negative numbers.

The approach adds the priority property when the plugin is being registered and then uses sortBy to sort the plugins before they are rendered inside the <PluginArea /> component.

How has this been tested?

This has been tested locally and using the unit and e2e tests.

Types of changes

New feature (non-breaking change which adds functionality)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[ryanwelcher]

This was broken out based on comments from @youknowriad on #13361

[ryanwelcher]

@youknowriad have you had a chance to think on this any further? Happy to make any changes as needed.

[paaljoachim]

Adding in what @youknowriad mentioned during the core editor meeting on the 11th September:
"To be honest, I'm not entirely sold on this because it's very tied to the implementation of the Slot. (not a fully semantic API).
I don't have a better alternative at the moment.
I know @matias have some thoughts about that as well."

[ryanwelcher]

Based on comments in the last #core-editor meeting, I feel I need to better explain this PR. I have created a new issue #18064 to track the intent.

@mcsf commented:

It seems that priority and order are very visually focused, in stark contrast with how Gutenberg has tried to use SlotFill so far.

The items that would be affected by this change are very much visually based. They appear in a certain locations of the admin - ie. Menu Items and sidebar panels

In Gutenberg, we talk about advanced settings, inspector, etc., instead of the visual element sidebar. Coming back to priority, what does it mean for SlotFill as far as selective rendering goes? how is a sequence determined semantically? etc.Why does this matter? Well, the bridging of different platforms and environments under Gutenberg is an important factor. If a codebase needs to work transparently across Web and Mobile, for example, its semantics needs to be clear and independent of a particular visual expression (e.g. Web on Desktop)

I want to make it clear, that this PR does not affect how a SlotFill is rendered and it doesn't interact with the SlotFill system in any way. It simply controls the order in which plugins( that contain SlotFIlls ) are rendered inside the PluginAreacomponent.

[jeffpaul]

@ryanwelcher care to resolve the merge conflicts so @etoledom could smoke test this on mobile?

[ryanwelcher]

@jeffpaul @etoledom Sorry for the delay on this! I have resolved the conflicts with latest trunk and made a couple of changes to reflect updates since this PR was created.

[jeffpaul]

@etoledom will you please smoke test this on mobile and report back your findings?

[jeffpaul]

@etoledom any chance you've been able to smoke test this on mobile?

[SiobhyB]

@ryanwelcher, @jeffpaul, apologies for the delay here! @etoledom isn't working on Gutenberg Mobile at the moment but has asked those of us currently on the team to take a look. I plan to take a look tomorrow.

As the PR hasn't been updated since May 2021, I'd be grateful if you had a chance to update with the latest changes from trunk first, but not a blocker to me mobile testing tomorrow if you don't get a chance. :)

[SiobhyB]

@ryanwelcher, @jeffpaul, I tested this locally on mobile by going through some of the main writing flows e.g. adding and editing multiple third-party blocks, uploading images, general formatting, etc. I didn't spot any regressions, and wouldn't expect any as we don't appear to use the registerPlugin function on the native side.

To test this, I had to update from trunk locally and made some assumptions about the way the merge conflicts with plugin-area/index.js would be resolved. I'll follow along with this PR and would be happy to test again after it's 'officially' updated from trunk.

[ryanwelcher]

@SiobhyB thanks for following up, I've been AFK for the holidays but will take a look at this shortly!

[michaelmcandrew]

I came looking for this functionality as a way to present a PluginDocumentSettingPanel directly after the 'Featured image' panel, though I would settle for anywhere after the Featured image panel if I couldn't get it to sit directly after.

My reading of the code and the default 10 makes me think positioning within current panels would not be possible. Thought it was worth mentioning it now in case it can be added to this PR / there is anythning that can be changed in this PR to make it easier to implement in the future.

[ndiego]

@ryanwelcher would you be able to update this PR with the last changes from trunk whenever you a sec? I would love to restart this discussion.

[emeaguiar]

Does anyone know if there's a workaround for this?

[ndiego]

Does anyone know if there's a workaround for this?

Not that I am aware of.