There’s a surprising amount of code here! This makes it less suitable for pedagogy. Can we use the standard embed code here? Is there something this code is doing that our standard embed code should be doing?
We could add a loading screen to the iframe embed; we discussed heuristics for assessing when an embed is done loading during our check-in this morning. Mike, anything you could suggest here with your knowledge of the runtime for assessing when the runtime has run enough for showing it to be useful would be helpful.
We can't add this resizing code until we add a script tag embed method (which is something we have working, but isn't slated for the initial release). I'll post a PR this weekend so it's an option, but our product decision was not to include the script tag yet. For this example, we could hardcode heights that are likely to look good instead, but it will make the page less responsive.
I agree it's unfortunate that the first example on the page is anything more complicated than html`<iframe src="https://observablehq.com/embed/@me/title" />`. Toph mentioned we could pull out a reusable userspace ObservableEmbed component for doing this resizing if the goal if for people to use it on Observable instead of teaching them how to write code to listen to the resizing messages themselves.
Removing the prefetch tag should cut half a second off of the load time here too, looking at an early draft of this notebook is what made me notice https://observablehq.com/@observablehq/slow-embeds-in-chrome
I also have to fix the width on mobile! (It's conspicuous there how we can't pass in height overrides.) Yeah, I agree it's bad pedagogy. Idk I'm thinking
Worth a brief intro to "what is embedding" for folks that may see this for the first time?
Thinking of the "why" or "so what" in the very beginning / tl;dr. Could also be posed in terms of questions to the reader. Just a thought.
I’m not sure what “Runtime with …” adds over just saying “JavaScript” or “React”. And it’s possibly more intimidating. What was the intent of this language change?
The JS/React methods have a lot more in common with each other than with the Iframe, and it helps to be able to talk about "the methods using the Runtime". We do also say they use the Runtime in the description, but I imagine fewer use it. I changed it after user testing; I am not attached one way or the other. I might try re-using the <RoleChoices/> rich dropdown from team settings so we can just title them Iframe / JavaScript / React and use the subtitles in the dropdown to elaborate.
Currently we still have eval=auto in the generated iframe code. I guess the one benefit of that is that we could change the default in the future without changing the behavior of past embeds
We'll look into it! Our oEmbed PR (https://github.com/iamcal/oembed/pull/479) on GitHub is still waiting to be merged, that might do it. But maybe we need to reach out to iFramely and give them a heads up. This currently works with Embedly because we worked with them directly.
Yes - it does seem to work on Embedly - thanks!
I notice, though, when I past your example URL in the Embedly code generator that the chart shows up but not the drop down menu.
https://embed.ly/code
Good catch, we're still working with them on this. Currently you get one cell, the last one in your url, because their default query param handing code only expects one value for cell=. So you can currently embed entire notebooks or single cells, but multiple cells are coming soon!
Hi @radames — I’m terribly sorry for the 3+ month delay, but I’ve finally fixed the Embedly issues (both viewof and multiple cells). It’s entirely my fault it took so long. Let me know if you have any issues.
What if I want to change some variable from outside the js embed, in the "host" webpage where the embed is now sitting, so the dataviz embedded changes... is there a way to do it?