Project todos

[KermanX]

Addons

• Addon Marketplace (related to RFC: Migrate to Nuxt #1392)
  • Directly use the Nuxt's module system or create a similar one?
• Consider theme as addon See Project todos #1515 (comment)
• Give addon more abilities
  • Hooks (feat: setting up hookable #1539)
  • Markdown Transformer (setupMdTransformer) (example use-case: feat: Implemented transformer for the wavedrom library #1503)
  • Page Templates (RFC: Custom UI layouts #1509)
  • Print templates and slide layers (feat: print templates, slide layers and rewrite export function #1513)
  • setupViteConfig: (config: Config) => Config instead of vite.config.ts
  • ✅ Custom routes (feat: setup for routes #1529)

Module resolution

• Bundle @slidev/client into @slidev/cli
• ✅ Optimize deps related (Don't force hoisting #1385: @vueuse/core)
  • Need help - may be Vite bug (fix: optimize deps errors in global installation mode #1559)
• ✅ Global installation related (Failed to install slidev globally on MacOS #1440,globally installed 0.48.8 seems breaking mermaid #1479,Slide export doesn't handle v-if in global-top or global-bottom based on conditional using currentPage, currentLayout #1490)
  • Deprecate global installation? Or how to fix it (fix: optimize deps errors in global installation mode #1559)
• Allow to customize user root (Discord thread)
  • Use .env or package.json or slide frontmatter?
  • slidev.config.ts?
  • Also helpful to Change path for layouts, components and etc. #1586
• ✅ Preserve comments in frontmatter when updating it (feat: preserve comments in frontmatter #1518)
  • Use yaml package instead of js-yaml

Features

• Auto animation (Universal Magic Move #1527). Is it possible to abstract shiki-magic-move into a more universal magic-move and a shiki "tokenizer"?
  • Very important feature
• ✅ Rewrite the VSCode addon (feat: rewrite VSCode extension #1557)
  • ✅ Support multiple slides in one workspace
  • If possible, Slidev language server ([Feature Request]: can add slidev language server? slidev-vscode#9). It could be better if Vue-Markdown language server is implemented first.
  • May require lots of work
• "loose mode" markdown: Parse markdown inside HTML unplugin/unplugin-vue-markdown#14

Performance

• ✅ Load the quick overview component after the current slide is fully loaded (perf: suspend QuickOverview and Monaco types loading #1526)
• Use Vite's warmup option (Blocked by Support module loading priority vitejs/vite#16523)
• Pre-compile UnoCSS for @slidev/client
• Only enable Monaco Editor when the render context is slides or presenter
• Reduce fs operations: finding setups and layouts

Chore

• Migrate CodeMirror to Monaco editor in side editor (RFC: Migrate CodeMirror to Monaco #1391)
• Rewrite Twoslash renderer (Twoslash strange behavior not in small windows #1414)
• Improve docs & clean up outdated translations

[cdtut]

#1392 Nuxt should enable a production build that doesn't need a running web server because it has SSG. Opening index.html from a browser on the same device should be enough to run the presentation which will be possible from devices when they are offline and can't install their own web servers such as phones and tablets.

[antfu]

I don't think we should replace theme with addons. To me addons should be a subset of theme, that mostly for extending Markdown Syntax or adding new components, but shouldn't change how the slide would work/look. Having two "themes" doesn't make sense either.

Yes if we move to Nuxt we could use Nuxt Hooks to extends the parsers and transformer etc. But that won't be happen very soon. Maybe we could adopt to use a custom https://github.com/unjs/hookable instance for now for addons and later we could just swap to Nuxt's.

[KermanX]

I don't think we should replace theme with addons. To me addons should be a subset of theme, that mostly for extending Markdown Syntax or adding new components, but shouldn't change how the slide would work/look. Having two "themes" doesn't make sense either.

I totally agree with you.

Yes if we move to Nuxt we could use Nuxt Hooks to extends the parsers and transformer etc. But that won't be happen very soon. Maybe we could adopt to use a custom unjs/hookable instance for now for addons and later we could just swap to Nuxt's.

I don't think unjs/hookable is very suitable for Slidev. Currently, the customization in Slidev is mostly based on setup functions. And AFAIK there are 3 ways to "customize" a procedure:

1. Register hooks, and call hooks in the procedure.
2. Call setup functions (signature: resolvedConfig => returnedOptions) and merge the returned options with the default one. Then execute the procedure based on the merged options.
3. Call setup functions (signature: resolvedConfig => currentOptions => newOptions) in a chain. Then execute the procedure based on the merged options.

(Now the CodeRunnersSetup and the ShortcutsSetup use the 3rd way, while the others (excluding side-effect-only setups) use the 2nd way.)

I think the 3rd way is the most "hackable" because addons can both add new options and edit the existing options. For transformer "hooks", in the 3rd way an addon can insert its transformer between any existing hooks, rather than only prepending or appending. For users, if two addons have conflicts, it would also be possible to remove the conflict hooks or re-ordering them.

---

About the addon marketplace, I meant something like https://nuxt.com/modules. It is of course OK to search the "slidev-addon" keyword in GitHub, but the search result is not intuitive enough I think.

[lucaslrodri]

#1430 It would be nice if the universal magic-move were inspired by Reveal.js Auto-Animate. In summary, Auto-Animate considers matching elements if they have:

• The same id (Priority - see the data-auto-animate-id attribute, explained here).
• The same node type and identical texts (or other identical attributes if necessary).
• For images, videos, and iframes, the src attribute is compared.
• The order in which the element appears in the DOM is also taken into consideration.

For situations where the automatic-matching algorithm is not feasible or does not provide the correct matching, you can add the data-magic-id property to the elements you want to animate. This property is prioritized over automatic matching.

In addition to the features of Auto-Animate, the following considerations can be taken into account:

• Code Blocks: Uses the shiki-magic-move algorithm.
• Equations: It would be interesting to implement magic-move in KaTeX equations. I believe that with this implementation, it's possible to create transitions like this one done in Manim. I'm not sure exactly how to do the implementation in this case, but I consider two possibilities:
  • The matching algorithm could take into account the LaTeX code combined with the Diff Match Patch algorithm, similar to shiki-magic-move.
  • Another option would be to take into account the rendered result of KaTeX, considering <span> tags.
  • ID implementation: Use raw HTML notation \htmlData{magic-id=a}{x} (or similar) to implement the transition functionality between elements with the same id.
• SVG: Smooth transitions between SVGs allow animating more complex shapes like diagrams and charts. In this case, we use the same rules explained earlier. In addition to CSS properties, SVG properties can be taken into account, such as:
  • Position (x, y),
  • fill, stroke,
  • d (<path>),
  • width and height (rect)
  • ...

Finally, users can modify (or extend) the automatic-matching algorithm, as is possible in Reveal.js Auto-Animate, by writing a custom automatic matching function, opening up the possibility of implementing plugins based on the magic-move feature.