[DEV-13852] Refactoring - Allow custom rendering of placeholders

[kudlajz]

EDIT: I have reworked all of the placeholder components that were using SearchInputPlaceholderElement to support custom placeholder rendering.

The main idea behind this refactoring is to simplify the rendering of placeholders, allowing full control over the contents of the placeholders as soon as they're clicked and to also improve the developer experience when adding or modifying the existing UI. Since a lot of the placeholder code will now be part of the consumer codebase, we don't have to release new versions of the editor when doing copy changes for example.

I chose the GalleryBookmarkPlaceholderElement as a proof of concept since it also contains the site switcher. The plan is (if we agree to it) to rework the remaining "search input" placeholders and then eventually rework the regular "input" placeholders as well.

The interface has been simplified into sort of a "headless" approach, so now the consumer only needs to provide a renderPlaceholder function that will receive different props based on the required logic.

This allows full control over the UI and also allows usage of consumer code's UI components instead of having to rely on the UI components present (or not present) in the editor. This way, we can get rid of things like invalidateSuggestions etc. that were more of a band-aid to the current solution rather than a proper fix.

In this case, the gallery bookmark placeholder rendering function will receive props like onSelect (when an option is selected) and onRemove (when we want to remove the placeholder).

For example, the onSelect callback expects a promise that will resolve to an object containing the OEmbedInfo of a given gallery, so we no longer need to provide fetchOembed to the editor and we can do all of this outside in the app.

You can see how the new approach is implemented in https://github.com/prezly/prezly/pull/15756.

Please also read the comment below and provide your thoughts on this approach.

[kudlajz]

I am still wondering if it's a good idea to have this half-approach where the "initial" placeholder UI is rendered by the editor, but then the subsequent UI is custom rendered.

I think ideally it would be nice if we could render the whole placeholder outside of the editor (i.e. rendered via renderPlaceholder function) but this would also mean that we would need to implement drag & drop functionality and other things (loading states, placeholder management etc.), so I wasn't sure if we should do it now or at all.

EDIT: We probably don't need to worry about placeholder management outside of the editor. It would still be internally managed by the editor as needed when using the respective callbacks.

The advantage of this "headless" approach is that we would have a complete control over the UI of the placeholders within the app and it will also allow other developers to bring their own UI (currently we force the placeholders to look the way they do, which I don't think is great).

Just wanted to hear your thoughts and opinions before I do the work, in case you don't think it's a good idea.

What do you think?

[e1himself]

I generally dislike how these extensions are structured with the code split between the app repo and the editor repo. Making the extension hard-to-use outside of the Prezly app. But hey! One step at a time! :)

With this refactoring I can definitely see that things become less complicated. And even though the code splitting issue is still there, it is a great improvement 👍

[fgyimah]

👍🏾