[lexical-list] Feature: Continuous list numbering #7059
Conversation
patrick-atticus
requested review from
zurfyx,
fantactuka,
acywatson,
Fetz,
ivailop7,
Sahejkm and
potatowagon
as code owners
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
the
CLA Signed
size-limit report 📦
|
| @@ -97,10 +97,35 @@ export function registerList(editor: LexicalEditor): () => void { | |||
| }, | |||
| COMMAND_PRIORITY_LOW, | |||
| ), | |||
| editor.registerNodeTransform(ListNode, $updateListNumbering), | |||
There was a problem hiding this comment.
I've tried to use node transforms where possible, but ran in to a bug with this approach (see video).
I know mutation listeners should not trigger additional updates, but one is needed to handle deleted list events. Would it be preferable to use it for all updates in this case?
CleanShot.2025-01-17.at.11.39.22-converted.mp4
There was a problem hiding this comment.
Updating from an update listener is the same anti-pattern as updating from a mutation listener. The reason for an update should always have something to do with something external to the editor's state.
There was a problem hiding this comment.
Regarding deletion I don't think there's a good way to react to a deletion that doesn't cause an update cascade, unattached nodes are ignored from transforms, something else would have to be added to the editor API in order to support this, whether that's something like an update listener that runs before transforms or a registerTransform-like API that executes in the cases when nodes are no longer attached.
I think a solution that depends more on DOM manipulation and CSS counters can be achieved without something like this though, shouldn't really even need a transform to support it.
| if (shouldUpdate) { | ||
| editor.update($updateListNumbering); | ||
| } |
There was a problem hiding this comment.
This is the update cascade anti-pattern. Mutation listeners are intended to be used for updating DOM or sending state out of Lexical but it's not a good idea to trigger another update in here. Code like this is not good for performance and can cause visual artifacts (two reconciliations for each related update) and and infinite updates when there's a bug.
Description
Currently, each new numbered ListNode starts it's numbering at "1". The user can create a new list with a custom start value by typing the number, followed by a period, followed by space (eg. "12. "). If the user tries to create continuous lists this way, they will not stay in sync when new items are added/deleted from previous lists.
Continuous lists are a feature of word/google docs accessed via the context menu and are important in certain types of documents:
This PR adds this feature via the following changes:
__continuePreviousNumberingto ListNodeTest plan
Included basic unit and playground tests, can add more if this PR is promising.
Demo:
CleanShot.2025-01-17.at.11.30.15.mp4