refactor!: slidem 2.0

[bennypowers]

new CSSStyleSheet is live in safari TP, so now's a good time

closes #25

[ruphin]

I found one more issue that seems to have crept in with the last release. If you make a custom slide (like slidem-polymersummit-slide) and define a background: ... css value, it is ignored unless you set !important because the css in slidem-slide-base.js always overrides the background even if the --background css variable is not set. Apparently constructed stylesheets take some kind of precedence over defining styles with <style>.

It's easy to fix by using constructed stylesheets in styled slides, but older slides with backgrounds that did not use constructed style sheets are effectively broken. Do you think you can find a way to fix this issue?

[ruphin]

I forgot to add that I appreciate the effort in maintaining this. :)

[bennypowers]

I found one more issue that seems to have crept in with the last release. If you make a custom slide (like slidem-polymersummit-slide) and define a background: ... css value, it is ignored unless you set !important because the css in slidem-slide-base.js always overrides the background even if the --background css variable is not set. Apparently constructed stylesheets take some kind of precedence over defining styles with <style>.

It's easy to fix by using constructed stylesheets in styled slides, but older slides with backgrounds that did not use constructed style sheets are effectively broken. Do you think you can find a way to fix this issue?

maybe with a css custom property? Or maybe customizing slides should only be via parts and css vars, not via extends?

[bennypowers]

We had previously discussed migrating to lit, i'm thinking it might be worthwhile to go in the opposite direction and remove all runtime deps

1. because of how simple gluon is, that would mean less refactoring
2. no need for imports / import maps

As part of that work, or subsequent to it, I suggest removing most of the build deps and instead using a custom compiler (perhaps a ttsc or esbuild transform plugin) and importing both the template and css files from .html and .css respectively. The runtime files would still be SFC's, but the authoring experience would have CSS-in-CSS

[bennypowers]

ok so this PR quickly grew way beyond it's original intention :D

It's now basically a full rewrite / slidem 2.0

• move templates and styles to separate files
• remove gluon dependencies
• remove FontFaceObserver dependency
• refactor router
• add state accessor pair
• remove docker, browsersync, rollup
• add esbuild, web-dev-server

BREAKING CHANGES:

• remove slidem-polymersummit-slide
• rename currentStep to currentStepIndex
• rename currentSlide to currentSlideIndex
• rename previousSlide to previousSlideIndex
• rename activeSlide to currentSlide
• remove ${'slide'|'fade'|'zoom'}-${'in'|'out'} and add in=zoom out=slide etc

To Test:

npm ci
npm start

Why remove Gluon? We don't really need any logic in templates, the previous template logic was essentially a prollyfill for css parts, but we have those now, so there's really no need. Personally, I don't think it's necessary to extend just to provide extra slots, when users can combine light css and ::part as I did with the polymersummit slides in the demo. As for the router, we only really need a subset of router features here (hashchange, popstate), and we can do the rest ourselves with URL and URLSearchParams. Having done that, the benefits to removing Gluon are apparent: SFCs, filesize over-the-wire, etc.

[ruphin]

This seems like a good idea. I was also thinking the build system is quite outdated and the dependencies could be cleaned up significantly. A few thoughts:

I think I prefer going completely without build system at all over one that's simplified. If we're going to strip it down might as well go all the way. At this point the build system barely adds any value, it only formats the html and css imports, and adds the copyright notice. To do this we only need to inline the CSS and HTML in the js files. We can use basic template tags so most code editors will know how to do the formatting:

const html = (strings, ...values) => String.raw({ raw: strings }, ...values);

// Or even this if they don't need dynamic parts
const html = (s) => s[0];

// And just inline like so
const template = html`<div>Template here</div>`

---

I'm not a huge fan of the bare addEventListeners in slidem-deck. window. is implicit but I prefer adding it to avoid any possible confusion (I had to double-take here to see if there was an addEventListener defined in the class).

---

The main purpose of the polymersummit slide was to demonstrate that you can make a custom element that defines a slide with some added style. The idea behind it being that you could make custom elements for specific decks, and create a library of sorts of different styles of decks, that you can consume easily:

import "https://slidem.ruphin.net/library/moden-style-slide.js";

const template = html`
<modern-style-slide>
  <h2 slot="title">Title</h2>
  <p slot="body">Lorem ipsum...</p>
</modern-style-slide>`

This got sort of lost in this refactor, it would be nice to retain this and see what authoring this type of custom element looks like.

---

Finally, I'm not sure what the instances in slidem-deck are for. Would you ever have multiple decks in a single document? I think that would lead to all sorts of issues with both decks sharing the same slide/step state.

I can help with applying some of these suggested changes. What are your thoughts?

[bennypowers]

going completely without build system at all

For me, I really like the advantages of writing CSS in .css files and HTML in .html files, and that outweighs the complexity of adding esbuild, which isn't that much IMO, there aren't huge transforms going on here, just inlining. You'll notice also that it's so fast that web dev server doesn't need any build-time transform plugins, it just refreshes on save with the new files, instantly. If this is a hard blocker for you, I understand, but perhaps there's room for you to be flexible on this?

bare addEventListeners

No problemo, we can put those back in

polymersummit slide

Yeah I don't mind that either, it's just not a case I've had much use for personally. If possible, could we add that back in as a subsequent docs update? I'd like to have this out for a talk I'm giving on the 9th (I can inline the sources if I need to, so NBD if you want to ruminate a bit longer)

instances

This is a trick I use to bridge the gap between the static side and instance side in classes. I suppose you could document.querySelector, but this way is more robust

I can help with applying some of these suggested changes. What are your thoughts?

Please!

[ruphin]

For me, I really like the advantages of writing CSS in .css files and HTML in .html files, and that outweighs the complexity of adding esbuild, which isn't that much IMO, there aren't huge transforms going on here, just inlining. You'll notice also that it's so fast that web dev server doesn't need any build-time transform plugins, it just refreshes on save with the new files, instantly. If this is a hard blocker for you, I understand, but perhaps there's room for you to be flexible on this?

You're more of a maintainer than I am at the moment so your proposed solution is fine. I will reserve the right to update it in the future if I ever work on this again. :)

I'm going through some testing and if everything looks good I'll release it as 2.0, Probably some time tomorrow.

[bennypowers]

fantastic! thanks for the review and for the release. I'm going to work on releasing my 11ty plugin which uses slidem under the hood, now

[bennypowers]

https://github.com/bennypowers/eleventy-plugin-slide-decks