Skip to content

book as nested chapters vs. separating chapters and ordering #2935

@wpmg

Description

@wpmg

Problem

I've tried to look around for context behind the nested structure of the book, but please excuse me if I haven't looked carefully enough.

Currently, a book is a nested collection of Chapters (or BookItems). I figure that this has been driven by SUMMARY.md being a nested list. However, I haven't been able to find the background, or the discussion behind this, so I don't really know the pros and cons.

In some cases, the nested structure creates obstacles: the iteration (esp. mutable iteration) is achieved through a lambda, rather than an Iterator. It also makes look-ups between chapters cumbersome (if there is processing dependent of different chapters). I also figure parallelization would become difficult (for independent chapters).

Proposed Solution

An alternative would be to separate the handling of the SUMMARY.md -- the ordering of BookItems -- and the content (Chapters). Say:

struct Book {
  chapters: HashMap<Id, Chapter>, // or just a Vec...
  summary: Vec<SummaryItem>,
}

enum SummaryItem {
  Chapter(ChapterItem),
  Separator,
  PartTitle(String),
}

struct ChapterItem {
  id: Id,
  sub_items: Vec<SummaryItem>,
  // ...
}

This would make it kindof straight forward to create a (mutable) iterator on Book (for Chapters), but might make it more cumbersome to programmatically add/remove Chapters.

I'm probably missing some important points, so please let me know!

Notes

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-enhancementCategory: Enhancement or feature request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions