In v49.2, is it by design that plugin handlers do not include DOM events anymore?

[MathiasGretland]

Hi!

I recently migrated my Editor to the newest version v49 where i could configure any plugin to have custom handler, based on what i wanted to achieve, such as for the Image plugin where i wanted all of the images to be converted to blob before insertion:

const insertImage = (editor, url, options = {}) => {
  const text = { text: "" };
  const image = {
    children: [text],
    type: "img",
    url,
  };
  editor.tf.insertNodes(image, {
    nextBlock: true,
    ...options,
  });
};

uploadFile: (file) => {
  const imageUrl = URL.createObjectURL(file);
  return Promise.resolve(imageUrl);
}

BaseImagePlugin.configure({
    handlers: {
      onPaste: ({ editor, event }) => {
        const files = event.clipboardData?.files;
        if (files && files.length > 0) {
          event.preventDefault();
          event.stopPropagation();
          event.nativeEvent?.stopImmediatePropagation?.();

          Array.from(files).forEach((file: any) => {
            uploadFile(file).then((url) => {
              insertImage(editor, url);
            });
          });
        }
      },
      onDrop: ({ editor, event }) => {
        const files = event.dataTransfer?.files;
        if (files && files.length > 0) {
          event.preventDefault();
          event.stopPropagation();
          event.nativeEvent?.stopImmediatePropagation?.();

          Array.from(files).forEach((file: any) => {
            uploadFile(file).then((url) => {
              insertImage(editor, url);
            });
          });
        }
      },
    },
  }) 

Here i override onPaste and onDrop to achieve what i want, and it works just fine as the handlers was typed like this handlers?: Nullable<{}>.

When i now updated to the newest version 49.2.12 i see that it has introduced onNodeChange and onTextChange, which are the only props that can be utilized without Typescript giving me an error. I figure this is because it lacked type safety before, but i wonder if this is by design and i should handle this use case elsewhere?

If i @ts-expect-error then i can the override kicks in and works as expected.

I guess i can have certain edge cases for DOM event placed on the <PlateContent> if i really need them, but i like to keep them in my plugin configurations for easier readability of custom logic that is specific to a plugin.

Also want to note down that this is not the only use case, i also do similar actions when working with the BaseCodeBlockPlugin. So, if i were to add logic for the custom handlers on the <PlateContent> instead then that would be significantly large to the point where its a bit unreadable.

Thanks in advance! 😄

Plate version

49.2.12

Slate React version

0.117.4

Browsers

Chrome

[dosubot[bot]]

Yes, this is by design in v49.2. The plugin handler API was changed to only support onNodeChange and onTextChange for editor state changes, and no longer allows DOM event handlers like onPaste or onDrop in the generic plugin handlers property. This change was made for type safety and to clarify plugin boundaries, as confirmed in PR #4549.

For custom DOM event logic, the recommended approach is to handle these events at the <PlateContent> (editor component) level, or use plugin-specific options if available (for example, DndPlugin's onDropFiles for file drops). Using @ts-expect-error to force DOM event handlers into plugin configs is not type-safe and not recommended.

If you want to keep custom logic organized, you can create small utility functions or hooks for each plugin's logic and call them from your main event handlers at the component level. This keeps things modular and readable, even if the logic isn't colocated in the plugin config itself.

Some plugins (like DndPlugin) still expose their own event handler options, but these are specific to those plugins and not part of the general plugin handler API anymore. For most cases, handling DOM events at the component level is now the standard pattern in Plate v49.2+.

See the PR and code changes for more details.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[zbeyens]

@dosu We still support DOM handlers, but only in the React version of plugins: PlatePlugin, not SlatePlugin

[dosubot[bot]]

Correct—DOM event handlers like onPaste and onDrop are still supported, but only in the React version of plugins (PlatePlugin), not in SlatePlugin. In PlatePlugin, you can use the handlers option to add DOM event handlers directly in your plugin config, for example:

const MyPlugin = createPlatePlugin({
  key: 'my-plugin',
  handlers: {
    onPaste: ({ editor, event }) => {
      // custom paste logic
    },
    onDrop: ({ editor, event }) => {
      // custom drop logic
    },
  },
});

This is documented in the plugin event handlers section and enforced in the PlatePlugin TypeScript types. SlatePlugin only supports onNodeChange and onTextChange, so DOM event logic must be handled at the PlatePlugin (React) layer or at the component level if you use SlatePlugin.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[MathiasGretland]

Thanks for the reply! ☺️

Follow up question: I do notice that some of the base plugins that plate offers are plugins of the type platejs.SlatePlugin, for example the BaseImagePlugin from @platejs/media, BaseTablePlugin and @platejs/table and BaseCodeBlockPlugin from @platejs/code-block.

Is it fine/safe to convert these over to PlatePlugin´s by utilizing the toPlatePlugin function from platejs/react, and adding the handlers logic in the extendConfig param the function has?

Example of what i mean:

toPlatePlugin(
    BaseImagePlugin.configure({
      node: {
        component: (...,)
      },
      parsers: {
        html: {
           ...,
        },
      },
      options: { ..., },
    }),
    {
      handlers: {
        onPaste: ({ editor, event }) => {
          const files = event.clipboardData?.files;
          if (files && files.length > 0) {
            event.preventDefault();
            event.stopPropagation();
            event.nativeEvent?.stopImmediatePropagation?.();

            Array.from(files).forEach((file: any) => {
              uploadFile(file).then((url) => {
                insertImage(editor, url);
              });
            });
          }
        },
        onDrop: ({ editor, event }) => {
          const files = event.dataTransfer?.files;
          if (files && files.length > 0) {
            event.preventDefault();
            event.stopPropagation();
            event.nativeEvent?.stopImmediatePropagation?.();

            Array.from(files).forEach((file: any) => {
              uploadFile(file).then((url) => {
                insertImage(editor, url);
              });
            });
          }
        },
      },
    },
  ),

[zbeyens]

Yes, that's a good practice.