Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Replace the renderBlockMenu prop with a Slot #7199
referenced this pull request
Jun 7, 2018
In general, I like the flexibility Slot & Fill gives, but there are a few limitations I described in my detailed comment. It helps to remove
renderBlockMenu from the
BlockEditContext which is great. If it works exactly as before, I would proceed. @aduth should have a much better idea if it fits.
While it's tempting to give developers full control over these items so far as the flexibility it provides, to me it seems like this isn't something a developer should want to be concerned with, and in its impact on opening the potential for inconsistent user experience (or even abuse), not something that has a net benefit for anyone involved.
Ultimately, what is a developer trying to do, and in what ways does order matter? For plugin developers, it seems like the mere presence in the list of options should be sufficient (though I'm open to hearing use-cases to the contrary). The complication for us here is that "Show Block Settings" is part of a core (post editor) behavior, and we do agree its sensible to be shown in a specific order (i.e. first in the list).
So how do we distinguish between:
Among plugin extensions proper, I personally don't think it's in the interest of anyone to introduce a concept of ordering. A single slot should be sufficient. To the user, its order in the list should be consistent (deterministic), but aside from that, I'd not care what metric is used for ordering.
For core behaviors, maybe it should be a separate slot from that of plugins, which prompts other questions:
Good thoughts @aduth we're often tricked by the fact developers want to extend everything for better and for worse. And often for worse in terms of UX for the user.
What's the way forward here, should we just rename the slot something like
I'd prefer if it was not available at all, though I cannot think of a solution for this currently. Seems reasonable to have as a naming convention for now, and since it's intended to be private, can be open for future backwards-incompatible refactoring.
I guess I don't like thinking of these as prepend and append behaviors, but rather within slots, each fill should be agnostic to its ordering. This is a strong "IMO" and is partly influenced by the complications which result by trying to introduce ordering / prioritization (though elsewhere we've relented, e.g. core block registration and transforms). Where the menu is effectively a set of slots / default items: