slidevjs / slidev

Presentation Slides for Developers
https://sli.dev
MIT License
33.63k stars 1.37k forks source link

Project todos #1515

Open KermanX opened 7 months ago

KermanX commented 7 months ago

Features

Addons

Module resolution

Performance

Chore

cdtut commented 7 months ago

https://github.com/slidevjs/slidev/issues/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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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:

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:

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.