@infonomic/payload-alternative-lexical-editor 1.1.5 → 1.1.6

package/README.md

@@ -1,21 +1,23 @@
-# Payload CMS 3.0 Alternative Lexical Rich Text Editor
+# Payload CMS Alternative Lexical Rich Text Editor
 
-An alternative adapter-based Lexical Rich Text editor for Payload CMS.
+An alternative adapter-based [Lexical rich text editor](https://lexical.dev/) for Payload CMS.
 
 > [!IMPORTANT]
 > Unless you have very specific needs, or a lot of experience with Lexical and custom Payload fields, you should almost certainly be using the official [Payload Lexical Rich Text editor](https://payloadcms.com/docs/lexical/overview). 
 >
 
-Before we dive in, it's also worth mentioning that creating a generalized and extensible editor with a 'pluggable' feature system — such as the one currently being developed the team at Payload, is an order of magnitude more difficult than creating an 'opinionated' adapter with limited extensibility. The Payload team are doing amazing work - and this repo and our editor is in no way a criticism of the work being done at Payload.
-
 ## Our Lexical Editor
 <img style="width: 100%" alt="lexical-editor-screenshot" src="https://github.com/user-attachments/assets/a41060c9-6f28-4b64-a045-c3fdd411d9af" />
 
 ## Background
 
-We started working with [Lexical](https://lexical.dev/) in 2022 while searching for a replacement CMS for our agency. We then discovered [Payload CMS](https://payloadcms.com/) - which ticked nearly every box, with one notable exception - the use of Slate as their rich text editor. We'd worked with Slate and other editors previously and really wanted to use Lexical.
+We started working with [Lexical](https://lexical.dev/) in 2022 while searching for a replacement CMS for our agency. We then discovered [Payload CMS](https://payloadcms.com/) - which was a pretty good fit for what we were looking for at the time, with one notable exception - the use of [Slate](https://github.com/ianstormtaylor/slate) as its rich text editor. We'd worked with Slate and other editors previously and really wanted to use Lexical. 
+
+We were also painfully aware of how difficult it is to work with Contenteditable-based editors - in particular for mobile support and especially on Android. Read this somewhat famous post from Jesse Jorgenson at [Prose Mirror](https://prosemirror.net/) - [Contenteditable on Android is the Absolute Worst](https://discuss.prosemirror.net/t/contenteditable-on-android-is-the-absolute-worst/3810). As an aside, [CKEditor](https://ckeditor.com/) has an excellent editing surface with very good mobile support (with solutions for most of Android's quirks) - it's just a shame that their model doesn't support structured content as its native serialization format (it expects HTML in and out - despite having quite a good internal model). Lexical's model and native serialization format is excellent - 'data in and data out', and mobile support is 'good enough'.
+
+And so we started work on a Lexical-based rich text field for Payload. 
 
-And so we started work on a Lexical-based rich text field for Payload. Early in 2023 we discovered [Alessio Gravili's Payload Lexical Plugin](https://github.com/AlessioGr/payload-plugin-lexical) which helped enormously in getting started with Payload and custom fields. We also attempted to 'give back' to the work Alessio was doing with contributions to his public repo.
+Early in 2023 we discovered [Alessio Gravili's Payload Lexical Plugin](https://github.com/AlessioGr/payload-plugin-lexical) which helped enormously in getting started with Payload and custom fields. We also attempted to 'give back' to the work Alessio was doing with contributions to his public repo.
 
 Thanks largely to Alessio's efforts, Lexical has now been adopted by the Payload team and is the default editor for Payload, which is fantastic.
 
@@ -35,7 +37,7 @@ Here are the main drivers for us wanting to maintain our own editor:
 
 5. In Payload 3.0 - we wanted to experiment with client-only forms using the new field api and `RenderFields`. You can see an example here in our [Admonition plugin](https://github.com/infonomic/payload-alternative-lexical-editor/blob/main/packages/payload-alternative-lexical-editor/src/field/plugins/admonition-plugin/admonition-drawer.tsx). This is totally experimental. It works (as far as we can tell) and we're using this for all of our custom components that require modals or drawers with Payload fields.
 
-6. We wanted to share our plugins - in particular our Inline Image plugin which was accepted into the Lexical playground and our Admonition plugin. In fact, our Inline Image plugin was one of the main reasons we chose Lexical as our preferred editor. Try creating a floated inline element that appears correctly in both the admin UI and the front end application - with any of the 'other editors', and you'll see why ;-).  Most of the other plugins in this repo track Lexical Playground plugins and are updated from there.
+6. We wanted to share our plugins - in particular our Inline Image plugin which was accepted into the [Lexical playground](https://playground.lexical.dev/) and our Admonition plugin. In fact, our Inline Image plugin was one of the main reasons we chose Lexical as our preferred editor. Try creating a floated inline element that appears correctly in both the admin UI and the front end application - with any of the 'other editors', and you'll see why ;-).  Most of the other plugins in this repo track Lexical Playground plugins and are updated from there.
 
 7. And lastly, we wanted to keep our editor lightweight and fast — in particular for longer documents.
 
@@ -94,7 +96,7 @@ The architecture of our editor is designed to solve the "two-way binding problem
 
 Rich text editors maintain their own complex internal state (the DOM/Virtual DOM). When you try to sync this with React state (props), you often get **infinite loops** (Editor changes $\rightarrow$ React updates $\rightarrow$ Prop changes $\rightarrow$ Editor updates $\rightarrow$ Editor changes...) or **cursor jumping** (re-rendering the editor while typing).
 
-In Payload - the adapter loads our editor via the `rsc-entry.tsx` stub and a component map entry in the [adapter](https://github.com/infonomic/payload-alternative-lexical-editor/blob/main/packages/payload-alternative-lexical-editor/src/adapter.ts). This follows the current adapter / component map strategy in Payload CMS itself. Note: Although the return shape of our editor is slightly different, the root of our editor document and SerializedEditorState is identical to the official Payload Lexical editor, and so migrating to or from the Payload version will depend primarily on what features or plugins have been used. 
+In Payload - the adapter loads our editor via the `rsc-entry.tsx` stub and a component map entry in the [adapter](https://github.com/infonomic/payload-alternative-lexical-editor/blob/main/packages/payload-alternative-lexical-editor/src/adapter.ts). This follows the current adapter / component map strategy in Payload CMS itself. Note: Although the return shape of our editor is slightly different, the root of our editor document and SerializedEditorState is identical to the official Payload Lexical editor, and so migrating to or from the Payload version will depend primarily on which features or plugins have been used. 
 
 ### Component Hierarchy 
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@infonomic/payload-alternative-lexical-editor",
-  "version": "1.1.5",
+  "version": "1.1.6",
   "private": false,
   "license": "MIT",
   "type": "module",