Project todos about slidev

[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.

[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.

[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.

[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.