You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Summary
There is a well-known issue with TipTap editor where it doesn't
necessarily check for its `isDestroyed` state, when trying to use e.g.
`commands`.
ueberdosis/tiptap#1451
Here this flow resulted in an uncaught error `Cannot read properties of
null (reading 'commands')`:
There was a found edge-case, when you re-rendered `EnrichedTextInput`
with new `htmlStyle` and `defaultValue`:
1. `resolvedHtml` changes because of the new `htmlStyle`
2. `tiptapContent` changes because of the new `defaultValue`
3. `useEditor` runs and recreates the input as `tiptapContent` changed -
this is a hook so actual recreation will happen after the render
4. `useEffect` with `commands.normalizeBoldInStyledHeadings` gets
scheduled to run after the render. The closure here captures the
**stale** `editor`, before `useEditor` actually ran.
5. After render `useEditor` successfully runs and updates `editor`
6. The latter `useEffect` runs with a `stale` editor, which crashes the
app
After the added check the `6.` will never run, but `editor` changed, so
the same `useEffect` will correctly run on the next render.
Provided safety-checks, when using `commands`, outside of the TipTap
internal state, in `EnrichedTextInput`.
all web e2e tests pass
## Compatibility
| OS | Implemented |
| ------- | :---------: |
| iOS | ❌ |
| Android | ❌ |
| Web | ✅ |
## Checklist
- [x] E2E tests are passing
- [ ] Required E2E tests have been added (N/A)
0 commit comments