Repository navigation
Replies: 1 comment
|
Named Slots look useful for modeling the independent editable regions of a page, but I would separate that concern from pagination/flow itself. For the structure you described, I would model the page roughly as: PageNode That makes sense because the header and footer are independent editable regions owned by the page. The harder part is the body overflow. I wouldn't make the slot mechanism responsible for pagination. Instead, I'd keep pagination as a higher-level layout concern that determines which content belongs to each PageNode. This also lines up with Lexical's newer pagination work: the Playground already has a So for a production implementation I'd lean toward: Document with a pagination/layout layer responsible for measuring the body and moving/splitting content between pages. One thing I'd avoid is treating every visual page as merely a container whose children are continuously reflowed by the editor tree. That can make selection, undo/redo, collaboration, and serialization considerably harder once content moves between pages. Named Slots are therefore a good fit for the header/footer isolation, but I wouldn't rely on them alone as the pagination architecture. The https://github.com/facebook/lexical/tree/main/packages/lexical-playground/src/components/Pages |
Uh oh!
There was an error while loading. Please reload this page.
Is Named Slots the recommended approach for building a paginated editor?
I'm building a page-based editor where each page has an editable header, body, and footer. The body content automatically flows to the next page when it overflows.
Would modeling each page as:
PageNode
├── header
├── body
└── footer
using Named Slots be the recommended architecture, or is there a better pattern for this use case?
All reactions