That's a pretty neat demo 💯 In terms of providing a component API usable outside of Portal, I have some questions: • Are there any assumptions about tech stack (react/...)? • How will the data be provided (cljs values/edn string)? • What does the UI build tools look like (shadow-cljs, npm)? • Is the notebook UI a single webview or some other configuration?

The easiest use case would be that you are using a reagent app in a single web view, then Portal could provide a single component that you can throw arbitrary data at, assuming they are cljs values. This component would understand it's running in an embedded context and remove some of the extra ui elements in Portal.

> That’s a pretty neat demo 💯 In terms of providing a component API usable outside of Portal, I have some questions: Thanks. I’ve been working with the vscode notebook API for work so I’m happy to throw my new experience at Calva. It actually only took around 4 hours to get that running from scratch. > • Are there any assumptions about tech stack (react/...)? Tech stack for Calva is pretty light right now, but we also aren’t opposed to including more stuff since the size isn’t really that important. > • How will the data be provided (cljs values/edn string)? edn string would probably be the easiest since we’re passing through typescript stuff on the way 😢 but I’ve mostly got full control over that part > • What does the UI build tools look like (shadow-cljs, npm)? Calvas build is not too complicated but it’s part typescript and part clojurescript. So we’ve got a shadow-cljs step that produces a :note-library target and a tsc step that does the rest and consumes the shadow artifact. > • Is the notebook UI a single webview or some other configuration? This is a good question 🙂 I haven’t fully looked into it yet. What I know already is that it’s a pretty flexible system, where you’re notebook execution produces a string that has a mime type. You can now separately register special renderers for mime types that get called when VSCode tries to render a value with that mime type. You can switch between multiple renderers, similar to portals views. There’s an example render that uses react, so it should be possible to get reagent running: https://github.com/microsoft/vscode-extension-samples/tree/main/notebook-renderer-react-sample

> The easiest use case would be that you are using a reagent app in a single web view, then Portal could provide a single component that you can throw arbitrary data at, assuming they are cljs values. This component would understand it’s running in an embedded context and remove some of the extra ui elements in Portal. This sounds like a good way to do it. I’d also be happy to show the full portal initially just to see if we can get it running. I’m just not really a react / reagent user, so I’d be thankful if you could help me with creating a portal UI version that can just be thrown into something like ReactDOM.render()or similar