fix(study): keep a numbered list counting when a block interrupts it #839

Merged
raisondetredev merged 1 commit from refs/pull/839/head into main 2026-08-17 17:15:48 +02:00
raisondetredev commented 2026-08-17 17:15:29 +02:00 (Migrated from codeberg.org)

A card whose back reads "1. …", code block, "2. …" showed both steps as
"1." in the study session while the editor showed them correctly. The two
disagreed about where a list starts.

AppFlowy does not store an ordinal on every item. It walks back over the
consecutive numbered_list siblings preceding an item and counts, so an
item whose previous sibling is something else opens a new run — and for
that item, and only that item, it reads an explicit number attribute off
the node, falling back to 1. That attribute is the entire record that a
list resumed rather than restarted, and it is what the editor renders from.

The read-only renderer never looked at it. It reset its counter to 1 on
any non-list block, which is right for a genuinely new list and wrong for
every list a code block, a note or a paragraph sits inside — the common
shape for "here are the two ways to do this", one listing per step.

_renderNodes now seeds the counter from number when an item opens a
run, and leaves later items in the same run incrementing as before, which
is AppFlowy's rule exactly. Reading it as num rather than int keeps a
value that survived a JSON round trip as a double from silently falling
back to 1.

FlashcardContentView is the only read-only renderer, so this lands on the
study session, the browser tiles, the previews and the PDF creator at
once.

Signed-off-by: Tizian 「ティツィアーン」 raisondetredev@pm.me

A card whose back reads "1. …", code block, "2. …" showed both steps as "1." in the study session while the editor showed them correctly. The two disagreed about where a list starts. AppFlowy does not store an ordinal on every item. It walks back over the consecutive numbered_list siblings preceding an item and counts, so an item whose previous sibling is something else opens a new run — and for that item, and only that item, it reads an explicit `number` attribute off the node, falling back to 1. That attribute is the entire record that a list resumed rather than restarted, and it is what the editor renders from. The read-only renderer never looked at it. It reset its counter to 1 on any non-list block, which is right for a genuinely new list and wrong for every list a code block, a note or a paragraph sits inside — the common shape for "here are the two ways to do this", one listing per step. `_renderNodes` now seeds the counter from `number` when an item opens a run, and leaves later items in the same run incrementing as before, which is AppFlowy's rule exactly. Reading it as `num` rather than `int` keeps a value that survived a JSON round trip as a double from silently falling back to 1. FlashcardContentView is the only read-only renderer, so this lands on the study session, the browser tiles, the previews and the PDF creator at once. Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
project-halkyon/halkyon-learn!839
No description provided.