CKEditor 5 not loading on formatted text Field Widgets in the component instance form

Not much point working on this until we can get CKEditor 5 loading on textareas #3512867: CKEditor 5 not loading on formatted text Field Widgets in the content entity form so postponing on that

The current MR is outdated to the point that it's probably not worth continuing, and will likely be less relevant after #3512867 so I'm going to hide that one and recommend a new MR starts once we have CKEditor 5 working in the fields that are configured to use it. #3512867 already has it the editor properly loading with formatted text fields in the Page Data form

MR has it working, still need to add tests.

There are PHP tests failing due to there being commented-out props in the all-props sdc. These are props unrelated to the work happening here, but their presence results an error occurring any time a value changes on any prop in all-props. It is being worked on in this issue: #3467959: SDC and code component props should be able to receive HTML, editable in formatted text fields+widgets

They're commented for now so the work being done here can be reviewed manually and the CK5 e2e tests pass. That should be enough to get this reviewed, but we shouldn't commit until #3467959 lands and we un-comment those props.

I did some manual testing of this and noticed after the first update of the preview (in response to an edit in a CKE field) there is a flicker as the form is rebuilt and then CKE is reattached. And from that point editing the field value doesn't trigger an update anymore. Here's an example showing I've put 'Hi dog what's up more edits' in the field but it doesn't trigger an update in the preview.

\

This turned out to be a pretty big thing to address, but it's good this came up and I have the underlying issue fixed. Instead of relying on Drupal behaviors, this is now using the Ckeditor5 React Integration.

Now the editors work without flickering and the preview updates as you'd expect. However, I've been at this for far too long and the code is a bit scary looking so it's switched to draft. There's some cleanup + the format switching will need to be refactored a bit to work with the React-rendered CKEditor5 components. I think this is for the best as CKEditor5 is probably too complex to graft the Vanilla JS version onto our React forms if there's an official React solution available.

I'm unassigned myself in case someone wants to jump into the chaos, but I'll be back at it tomorrow.

Sorry @ anjali your name is right next to "Unassigned"

The flickering reported earlier wound up being a pretty big deal and I switched out the drupalBehaviors grafting to instead use the React solution from CKEditor themselves.

The only failing e2e test is the recently addedfield_xbt_entity_ref_tags which was added to day and should(?) be unrelated to anything here.

The MR should probably have gotten another once over from me before switching to NR, but I gotta leave the computer + this is high priority and probably good to get some eyes on it

Pausing the NR - spotted something locally that could be improved

I want to zoom out and look at what our intent/hope is with "Redux-integrated field widgets" ("keep existing widgets working without significant changes") versus the reality here

Maybe this should be a separate issue? This is higher level than just CKEditor5 , and our decision to use Radix has necessitated far more complexity than anything in this issue.

I also think this is based on an assumption that this introduces unprecedented special-casing which I don't really think it does.

So: can we be confident that this deep special-casing will be only necessary for very complex widgets like this one?

• It's not particularly deep special casing IMO. The majority of what might be seen as complex is code copied from core's ckeditor5.js. If the code wasn't encapsulated we could have called it directly and reduced the MR size significantly
• What is largely happening in the MR is I opted to use an already-available React component recommended by the CKEditor5 team. It's an existing React solution for exactly what we need. The CK5 implementation has required less bending-to-our-will than the decision to use Radix has required.

Is it extra complex because we're only going to allow these 2 specific locked text formats/editors in component instances?

No, nothing in the React or semi coupled code was any more/less complex because of the that. It just works with whatever is made available to it.

There was additional complexity due to the design decision to hide the format select element behind a popup and render that element with Radix instead of making it a standard select.

OW: can we document why this is so complex and special? 🙏 A new section in docs/redux-integrated-field-widgets.md perhaps?

I still don't think this stands out as novel in its complexity

If documenting additional complexity in the Render Array -> React layer seems beneficial, justifying the complexity introduced by Radix should probably get the emphasis, which would be out of scope here. I think this could be worthwhile to do in a separate issue.

Does this need review from me, @bnjmnm? 😇 Would like to land this one! :D

Not yet. #24 & #26 opened a can of worms and this will be another few days at least, potentially longer depending on how many rounds of revisions are requested on the docs.

Upon discovering that much of the implementation I was fighting against was done due to lack of designs vs something intentional, I gutted it and replaced it with something that required fewer hacks & workarounds. It's not suddenly simple, but all the steps are very clearly geared towards the implementation the CK team's CKEditor 5 React component, instead of wiring disparate parts together.

Functionally this is basically ready to go (I'm sure there will be some changes requested in review) but the following need to be considered

Current Limitations

• The dialog that appears when the text format changes is not currently implemented. For the component instance form this isn't an issue since there's only one format. It could be taken care of in a followup
• The text format info below the field does not change based on the format changing. This is nothing new, just more noticeable with a fully working editor. This could be done in a followup

Documentation Needs
This could take a while for a few reasons

• Documentation that properly addresses the concerns expressed in #24 and #26 needs to provide context beyond CKEditor5 implementation. For example, there's arguably more complexity due to using Radix instead of fully authoring our own templates. Highlighting one example without sufficient context can lead to overattribution and misunderstanding. This is information worth documenting, but it's a big topic that needs to be addressed thoughtfully. So this could take some time especially because....
• It's likely it will require several rounds of feedback much like this documentation issue did: #3446434: Document "Semi-Coupled Theme Engine" and "Redux-integrated field widgets" components

Added two followups

• #3522998: [later phase] CKEditor 5 - expand format select functionality on content entity form (this is more relevant to page data forms and is a refinement that can be done later while the significant improvements go in here)
• #3522999: Document use cases where XB's field widgets don't 1:1 match how they would work in a twig theme (@lauriii requested this be done in a separate scope)