swap reveal.js instead of swiper for slides#9166
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Bundle ReportChanges will increase total bundle size by 225.98kB (0.91%) ⬆️. This is within the configured threshold ✅ Detailed changes
Affected Assets, Files, and Routes:view changes for bundle: marimo-esmAssets Changed:
Files in
Files in
Files in
Files in
Files in
|
There was a problem hiding this comment.
Pull request overview
Swaps the notebook “slides” layout implementation from a Swiper-based deck to a Reveal.js-based deck.
Changes:
- Added Reveal.js dependencies and introduced a new
reveal-component+ Reveal-specific styling. - Updated the slides layout renderer and e2e tests to target Reveal’s DOM structure/classes.
- Refactored Swiper styling by moving Swiper-specific CSS into a dedicated stylesheet imported by the Swiper component.
Reviewed changes
Copilot reviewed 9 out of 10 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
pnpm-lock.yaml |
Locks new @revealjs/react and reveal.js dependencies. |
frontend/package.json |
Adds @revealjs/react and reveal.js to frontend dependencies. |
frontend/src/components/slides/reveal-component.tsx |
New Reveal-based slides deck component used by slides layout. |
frontend/src/components/slides/reveal-slides.css |
Reveal-specific CSS overrides to better match marimo styling. |
frontend/src/components/editor/renderers/slides-layout/slides-layout.tsx |
Switches slides layout renderer to use Reveal component and maintain an external deck ref. |
frontend/e2e-tests/slides.spec.ts |
Updates e2e assertions/navigation checks for Reveal. |
frontend/src/components/slides/slides.css |
Removes Swiper-specific styles, keeping only shared slide layout styling. |
frontend/src/components/slides/swiper-slides.css |
New Swiper-specific stylesheet (imports Swiper CSS + theme overrides). |
frontend/src/components/slides/swiper-component.tsx |
Imports the new Swiper-specific stylesheet. |
frontend/src/plugins/layout/carousel/CarouselPlugin.tsx |
Updates lazy import to point at swiper-component. |
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
| <Tooltip content="Fullscreen (F)"> | ||
| <Button | ||
| data-testid="marimo-plugin-slides-fullscreen" | ||
| variant="ghost" | ||
| size="icon" | ||
| className="absolute top-2 right-2 z-10 opacity-0 group-hover:opacity-70 text-muted-foreground transition-opacity h-7 w-7" | ||
| onClick={() => { | ||
| deckRef.current?.getViewportElement()?.requestFullscreen(); | ||
| }} |
There was a problem hiding this comment.
The fullscreen button calls requestFullscreen() unconditionally on the viewport element. In embedded/iframe contexts or browsers where fullscreen is disabled, this can throw (or reject) and create an unhandled error. Consider using useIframeCapabilities().hasFullscreen (as in swiper-component.tsx) to conditionally render/enable the button, and invoke fullscreen with a safe check (e.g., guard for element?.requestFullscreen and handle the returned promise).
e7390e1 to
cf6d1bd
Compare
f6c76b7 to
cf6d1bd
Compare
b74a497 to
a85f667
Compare
peter-gy
left a comment
There was a problem hiding this comment.
This is great!
I could also test some revealjs-native features like lightboxes https://revealjs.com/lightbox/, and it works out of the box, which is really cool:
just by adding the data-preview-image attribute.
mo.vstack([
mo.md("# LightBox"),
mo.Html('<img src="https://picsum.photos/seed/vs1/2000/1500" data-preview-image />'),
])This made me wonder if, as a follow-up, we'd want to extend mo.image to accept attributes so that when authoring slides we can do something like:
mo.image(
"https://picsum.photos/seed/vs1/2000/1500",
attributes={"data-preview-image": True},
)A few other follow-up questions came to mind:
-
Should
Escapetoggle back to edit mode when presenting slides? I caught myself hitting Esc out of muscle memory and expected to go back to edit mode. -
Reveal supports vertical slides (https://revealjs.com/vertical-slides/). Do we want to map notebook structure such as vertical / column layouts onto horizontal / vertical slide navigation? It could give large notebooks a minimap-like navigation like this:
@koaning could have nice use cases for it based on the columned notebook demo we've seen from him at the all hands.
- Do we want to support revealjs plugins as a follow-up? That could give users access to nice features like Markdown slides (https://revealjs.com/markdown/) and speaker view (https://revealjs.com/speaker-view/). Or instead of having a pre-defined list, we could let users hook into the reveal init lifecycle via custom script they write e.g. in custom HTML Head of notebooks?
None of these feel blocking to me, but they seem like high-impact next steps now that the core integration is in place.
|
|
||
| return ( | ||
| <div className="group relative h-full w-full flex-1"> | ||
| <Deck |
There was a problem hiding this comment.
Do we want to support revealjs plugins?
Maybe a lean default set like
<Deck
plugins={[RevealHighlight, RevealMarkdown, RevealNotes]}
...for code highlight (https://revealjs.com/code/), reveal-native markdown rendering (https://revealjs.com/markdown/) and speaker notes (https://revealjs.com/speaker-view/)
Yeah, I intentionally disabled it since we had the minimap, but yes I can toggle this back on.
That's interesting..This would require some brainstorming. Currently the slides are arranged linearly in cell order, so different columns would be way further down.
Yeah, that makes sense. Can add base ones. We already have marimo markdown.., but hmm. Also love if users can hook them in. Or, we could have a dropdown, and users could check which ones they'd like to add in. And we will lazily import. Adding tickets for these |
|
🚀 Development release published. You may be able to view the changes at https://marimo.app?v=0.23.2-dev55 |

📝 Summary
Swap libraries from Swiper to Reveal.js for slides view. I still maintained the old components because Carousel Plugin uses them.
Screen.Recording.2026-04-14.at.12.33.05.AM.mov
Todo:
Update pdf export flowsI've tested exporting pdf with slides, and it seems to work fine as is, even with
raster-server=live. We may want to use a different approach in the future (once we support showing code inputs). I experimented with usingprint-pdfon the URL and it doesn't work as well in the marimo editor. But I may have another approach for us (use vertical layout instead).Future PRs:
kitchen_sink_slides.pynotebook (may do it in a follow-up b4 merging this)📋 Pre-Review Checklist
✅ Merge Checklist