gatsby-remark-embedder
gatsby-remark-embedder copied to clipboard
feat(Excalidraw): Add support for Excalidraw
This branch adds support for Excalidraw links using the technique from https://github.com/excalidraw/gatsby-embedder-excalidraw. It closes #121
Checklist:
- [x] Documentation
- [x] Tests
- [ ] Ready to be merged
@trevorblades @j-f1 Like I already said in excalidraw/gatsby-embedder-excalidraw#2, I think it would be better if we had one of the following options instead of using puppeteer
, since that's quiet a big dependency:
- an oembed endpoint
- an iframe embed
- an endpoiint to get the svg
Not only is puppeteer
a big dependency, it's also harder to test/mock.
I'd love to have an @excalidraw transformer built into the plugin, but I don't think using puppeteer
is the right approach tbh 🤔
Maybe @kentcdodds has some thoughts on this too?
I think it should be pretty simple to put this into a separate package and then:
module.exports = {
// Find the 'plugins' array
plugins: [
{
resolve: `gatsby-transformer-remark`,
options: {
plugins: [
{
resolve: `gatsby-remark-embedder`,
options: {
customTransformers: [
require('name-of-excalidraw-embedder-module'),
],
services: {
// The service-specific options by the name of the service
},
},
},
// Other plugins here...
],
},
},
],
};
I really don't think that this should be added into core when it requires installing puppeteer.
@kentcdodds gatsby-embedder-excalidraw
is already available as a separate package.
I'd love to have it built into the plugin by default, but the puppeteer dependency is making me hesitant too.
If there's a way we could figure this out with the @excalidraw team, I'm all in!
I think it makes sense to keep this as a separate package as long as it relies on puppeteer. I'm not sure if it's on the roadmap or something that they'd want to do, but if Excalidraw supports oEmbed or public image URLs in the future, we can pick this back up and create a dependency-free implementation.
The (nice?) thing about this method is that it outputs raw SVG code in the markup rather than pointing to an image/embed link hosted on another domain, so it only needs to make a network request to Excalidraw once during the build phase.
@travorblades having an endpoint that returns the svg markup is fine by me too.
That can also be achieved when at the same time being compliant to the oembed structure/standard
One security concern is that if Excalidraw renders the drawing on the server, it needs to be passed the decryption key (which goes against end-to-end encryption), whereas the Puppeteer method never sends that information to the server. Theoretically we could implement this as a Node module so we don’t need Puppeteer but that’s a ways down the line.
@j-f1 It maybe could be easier to be oembed compliant instead? 🤔
Just doing a call to https://excalidraw.com/oembed/url=XXX which returns a JSON object having an html
key we could use in this plugin
Anything server side would still need to decrypt the stored drawing though, right?
@j-f1 That's what's happening at this moment too when clicking the button (like you do with puppeteer
), right? 🤔
No that happens on the build server — the end to end encryption means the excalidraw server never sees drawing content right now.
@j-f1 The oembed
endpoint could internally send a request to the build server and pass back that response as the html
key then I think?
I don’t quite understand. “Build server” here means wherever you run Gatsby.
@j-f1 I think we're talking next to each other, could you maybe DM me on Twitter to explain it to me please? I think it's just me not understanding what you're saying and I don't want to make this PR polluted
It would be amazing if there was a solution without puppeteer. let me know if i can help.