Performance/lag issues with Grammarly extension?

[alex-breen]

My app is having noticeable performance delays while typing into a slate text editor when Grammarly (chrome extension) is invoked. There is a lag from keystroke to seeing the text updated on the screen. What I've noticed is that if I disable Grammarly (or it does not invoke on screen), the lag problem is no longer observed.

In addition, Grammarly acts inconsistently in general - sometimes it is invoked, sometimes not, and while scrolling the page the "Grammarly red underlines" "move" with the scroll, instead of staying with the word. The page often has more than one slate.js editor running (ie, picture a message list with a slate editor for each message). but even with just one editor invoked on the page, performance drops as soon as Grammarly appears.

I can't reproduce this problem on the slate rich text example ( https://www.slatejs.org/examples/richtext ). My code is very similar though. I can't spot any significant differences.

So I'm really at a loss as to what I'm doing wrong. Does anyone have any suggestions for what I can do to alleviate this? (I realize it likely has nothing to do with Slate itself.) Thanks to anyone who can help!

Development environment:

• Chrome (109)
• Grammarly extension (14.1094.0)
• React
• Slate.js imports:
  {Editor, Transforms, createEditor, Element, Node, Text } from 'slate'
  {Editable, withReact, useSlate, Slate } from 'slate-react'
  {withHistory} from 'slate-history'
• Slate.js versions: [email protected], [email protected] [email protected]

[alex-breen]

Update:

1. Performance: This is largely my own fault. I had coded the child components of the formatting toolbar for Slate so that they rendered inefficiently. The repeated renders likely resulted in Grammarly over processing and slowing down the page.
2. Red underlines "moving": This is not related to Slate. It occurs if contenteditable elements are inside flex-direction column-reverse. I reached out to Grammarly and their developer support confirmed they could reproduce it. So hopefully this will be fixed in a future update of the Chrome extension. In the meantime, the desktop (Windows) version of Grammarly works fine under the same conditions.