Audit experimental features in Editing Toolkit

[WunderBart]

Master tracking issue: #44251

Editing Toolkit is dependant on experimental features without a fallback for a scenario where such a feature is not supported anymore. Below is a list of usages that we need to update in this matter:

• dotcom-fse: Audit experimental features in ET/dotcom-fse #46520
• event-countdown-block: Audit experimental features in ET/event-countdown-block #46519
• global-styles: Audit experimental features in ET/global-styles #46522
• premium-content: Audit experimental features in ET/premium-content #46523
• wpcom-block-editor-nav-sidebar: Audit experimental features in ET/wpcom-block-editor-nav-sidebar #46524

[WunderBart]

@Automattic/cylon is this something that you could look into?

[noahtallen]

@WunderBart I think we might need to split this across the teams who worked on each area of the codebase since we are really only familiar with dotcom-fse.

/event-countdown-block

cc @mkaz

/global-styles

cc @nosolosw

/premium-content

cc @Automattic/serenity

/wpcom-block-editor-nav-sidebar

cc @p-jackson

[WunderBart]

Thanks for mentioning the right folks, @noahtallen! 🙌

I've split this one into separate issues (see updated description) and created a milestone for the ET. I hope this will help organize this task better.

[oandregal]

👋 I've received the pings and would like to understand how can I help here: is it your goal to audit if an unstable/experimental usage is ok or does it need updating based on WordPress 5.6 stabilization task?

This is what I can say about the code for Global Styles: apparently, __unstableIsEditorReady was introduced as a patch specific for WordPress.com/iframed editor at #40690 It is an API that will remain as it is for the time being, so it's safe to keep using it.

---

In case the goal was to remove any unstable/experimental API. From what I gathered reading that issue, it looks like the problem was that the stylesheet generated in the client by the Global Styles plugin upon user changes needs to be appended after Gutenberg's own editor styles (which is somehow messed up by the iframed editor). This is what's happening:

1. GS (server) sends to the block editor some pre-calculated styles via the block_editor_settings, so they are wrapped by the .editor-style-wrapper.
2. GS (client) adds a new styleshet with new styles if the user made any changes. This needs to be loaded after 1.

A few alternatives that come to mind to get rid of the __unstableIsEditorReady would be:

• given that user changes can only happen when the sidebar is mounted, etc, is there any other editor event this can be hooked to?
• change how the styles work for the editor: do not send the existing pre-calculated styles and instead generate them all in the client.

[WunderBart]

👋 I've received the pings and would like to understand how can I help here: is it your goal to audit if an unstable/experimental usage is ok or does it need updating based on WordPress 5.6 stabilization task?

👋 @nosolosw, thanks for your reply. Our goal is to make sure experimental features don't accidentally break the code that depends on them. This means either providing a fallback mechanism (i.e. like this one) or an alternative implementation as you mentioned. I didn't notice the __unstableIsEditorReady to be mentioned in the 5.6 stabilization task so I asked about adding it. Do you think you could own the #46522? I guess it's OK too if we leave it to the Create Focus Maintenance folks. I will copy your comment to #46522.

[oandregal]

I don't think I can own that refactor but can provide support, pointers to where to start, or reviews if that's helpful to folks.

[sirreal]

Closing this as of #47712 / p4TIVU-9xW-p2