[lexical-table] [lexical-selection] Try to fix calling split on undefined

[ivailop7]

Second highest error rate leading to editor crashes we are observing is the following error:
"Cannot read properties of undefined (reading "split")..."
Unfortunately, I don't know how to reproduce the error.

Have gone through the whole codebase and everywhere we call 'split' and have narrowed it down to 3 places (insertRawText method + the 2 in this PR), my gut feeling is that it's probably the table cell method, but the other 2 also could do with the defensive if statement.

EDIT: Will start only with the table plugin and CSS parsing edits

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
lexical	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 20, 2024 9:56pm
lexical-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 20, 2024 9:56pm

[github-actions]

size-limit report 📦

Path	Size
lexical - cjs	29.94 KB (0%)
lexical - esm	29.78 KB (0%)
@lexical/rich-text - cjs	38.51 KB (0%)
@lexical/rich-text - esm	31.58 KB (0%)
@lexical/plain-text - cjs	37.16 KB (0%)
@lexical/plain-text - esm	29 KB (0%)
@lexical/react - cjs	40.29 KB (0%)
@lexical/react - esm	33 KB (0%)

[etrepum]

I don't love adding defensive code that ignores input when the types are wrong, it's just hiding some incorrect cast somewhere else if these are anywhere near the actual problem. Maybe a better option would be to add a typeof string invariant to getStyleObjectFromRawCSS if that's a suspect and then you'd at least know that's where the failure is?

The textDecoration case seems awfully unlikely because that looks like a DOM node and those shouldn't have these kinds of surprises

[ivailop7]

I don't love adding defensive code that ignores input when the types are wrong, it's just hiding some incorrect cast somewhere else if these are anywhere near the actual problem. Maybe a better option would be to add a typeof string invariant to getStyleObjectFromRawCSS if that's a suspect and then you'd at least know that's where the failure is?

The textDecoration case seems awfully unlikely because that looks like a DOM node and those shouldn't have these kinds of surprises

Agreed, but I think for these 2 the changes make sense.