Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Project todos #1515

Open
KermanX opened this issue Apr 11, 2024 · 4 comments
Open

Project todos #1515

KermanX opened this issue Apr 11, 2024 · 4 comments

Comments

@KermanX
Copy link
Member

KermanX commented Apr 11, 2024 •
edited
Loading

Features

Addons

Module resolution

Performance

Chore
@KermanX KermanX pinned this issue Apr 11, 2024
@cdtut
Copy link

cdtut commented Apr 11, 2024

#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
Copy link
Member

antfu commented Apr 11, 2024

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
Copy link
Member Author

KermanX commented Apr 12, 2024

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
Copy link

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

@KermanX KermanX mentioned this issue Apr 13, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@antfu @lucaslrodri @KermanX @cdtut