Enable to step through fragments inside a slide about mdx-deck

[jxnblk]

Might or might not be useful for this feature, but I've added some context for use in the presenter mode and speaker notes. There are now withDeck and withSlide higher order components to hook into the two contexts.

Example usage here: https://github.com/jxnblk/mdx-deck/blob/master/src/Notes.js

[busypeoples]

I think we can close this due to #37

And we can create a new issue regarding routing when needed.

[busypeoples]

Added a proof of concept. #37

[jxnblk]

Edit I thought I clicked submit on this comment, but apparently didn't, so this is from a few hours ago...

Thanks! I'd love to support this. In my mind, there's a few pieces needed for this:

• A way to represent this in the URL (e.g. #3.0, #3.1) and work with the keyboard shortcuts/UI controls
• A React component that works with this – could either be limited to lists or maybe something like:

<Reveal>
  <ul>
    <Step>
      <li>One</li>
    </Step>
    <Step>
      <li>Two</li>
    </Step>
    <Step>
      <li>Three</li>
      <li>Multiple at once</li>
    </Step>
  </ul>
</Reveal>

With that in place, we could consider a way to render this in markdown syntax.
I'm hesitant to introduce any non-standard syntax, so it might mean using code blocks to render the component:

```.reveal
- One
- Two
- Three
```

[jxnblk]

Thanks for the PR – looks like you've got the same idea with a component based approach 👍

Any thoughts on how (or if) this should tie into the main app state? Looking at what you've got, it might be fine to handle this with up/down arrows and have it's own state 🤔

[busypeoples]

Yes, it would be actually be great to not make the state local. What if we pass down a callback from the top level component and keep everything in one place. Also excellent point regarding extending the url via #3.1. We could also consider figuring out how to pass down the click events, which would enable us to use the left / right keys.

[busypeoples]

I will try to improve the PR. I like the idea of defining it more explicitly. So maybe instead of
using a -, We don't care about how the block is defined, f.e.

  <FragmentBlock>
    <div>Based on OCaml</div>
    <div>Types</div>
    <span>Community</span>
    <div class="some-effects">Interop</div>
  </FragmentBlock>

[jxnblk]

Yeah, we don't have to boil the ocean here, but could be cool if the component could still be used to do more custom reveals, like images on the left and right, etc.

As far as the keyboard events go, I think that the keyboard shortcuts could be nice to pull out into their own component, and maybe it works as a context provider as well??

[jxnblk]

And whatever the component ends up as, it could be used for rendering a fenced code block or custom remark block maybe

[busypeoples]

Yes, that would be perfect, regarding the key events.
I already updated the PR to enable to reflect the reveal structure.

Edit: Actually you could even keep the key events inside the top level component, and pass them down via provider?

[busypeoples]

I think we might run into a number of problems when trying to provide keyboard events via context.
Anyone can subscribe, which means any slide (even if not active) can take over the control. The problem is that the components don't know if they currently active, which makes sense.
I built a quick prototype, the problem is that even if the slide is not active, it will be able to take over the key event. Just noticed this code :

{slides.map((Component, i) => (
    <Slide key={i} id={'slide-' + i}>
        <Component {/* pass down a subscribe function */} />
     </Slide>
))}

This is where we know what slide is active. So instead of anyone being able to subscribe, what if only the active slide can subscribe to the events? But from what I understand, we can't pass any props through Component.

[jxnblk]

Ah, good point... I wonder if the SlideDeck app's state should be provided as context, which could be used as a private API for things like this fragment/reveal block?

But from what I understand, we can't pass any props through Component.

For now yes, but I think it's coming back around to allowing props to be passed through again.

[busypeoples]

I would guess we can pass down the update function as well as the app's state via context. We could even make the url the single source of truth, like you mentioned before #3.2, would mean we're inside a fragment block and we're at step 2. I'm working on a prototype right now.

Edit: What if we pass down a wrapped history function? We might not even need any state.
What should happen when we navigate back from 5 to 4 (and we have 4 fragments): it should be #4.4 right?

[jxnblk]

As far as the update method goes, yeah – I like the pattern of simple updater functions that can be shared throughout an app.

I like where you're going with the wrapped history function – I think it'd be great to keep all state in the URL – if that is better handled using something like react-router/reach-router/etc, I am also okay with introducing some deps for that sort of thing

[busypeoples]

In which direction should we try to explore?

What should happen when we navigate back from 5 to 4 (and we have 4 fragments): it should be #4.4 right?

If we need to jump back #4.4, then this would mean that fragments can't just be an add-on but part of how mdx-deck works. f.e. type slide = list(fragments).
If you don't care about jumping back to #4.4 but instead jump back to `#4 , then we wouldn't need to make fragments first class. In this case. Thinking about it, maybe keeping the current step inside as local state, could even be very beneficial. We could even update the url depending on the current step, as soon as the slide is active.
I can build two or three different examples, so we can compare and iterate further.

[jxnblk]

Yeah it’s a tricky problem for sure. I’m mostly going off of what I think users will expect based on apps like Keynote