Open fkling opened 8 years ago
Here is my talk about CSS isolation if you will think about React component: http://ai.github.io/postcss-isolation
Selectors isolation from Inline Styles is not enough.
IMO iframe is the best (time-proven + framework-agnostic) way to resolve this, but need to work out the details - how it will look like, what can be customized etc.
Current idea/plan: Create a script that can be loaded and which exposes an API that lets you render astexplorer into a given element. Something like:
<link href="path/to/astexplorer.css" />
<script src="path/to/astexplorer_embed.js"></script>
<script>
astexplorer.render({
parser: 'acorn',
parserSettings: {
// ...
},
code: '...',
// transform: ...
// etc.
}, someElement);
</script>
That would make it easy to configure examples. For that I still have to do
Would be great to get the babel repl to use it (although we want to be able to specify external presets/plugins and options)
I would love to be able to embed AST explorer on our website https://scalameta.org/docs/trees/scalafiddle.html We already embed a "ScalaFiddle playground" through an iframe to interact with our public APIs and it would be great if we could do something similar with AST explorer.
BTW thank you for AST explorer. It's been very helpful in educating our users how to implement refactorings for Scala source code.
This issue is quite old. Any progress done?
People reached out to be and showed interest in an embeddable version of astexplorer. This thread should explore how this would look like and what needs to be done.
I think there are two ways to achieve this and ideally we can support both:
<iframe>
.1.
<iframe>
This should be fairly straightforward. The URL could contain UI options, such as the chosen parser, chosen transform, which visualization to show, whether switching parsers is allowed or not, etc. Basically just ways to configure how astexplorer looks like and optimize it a bit for smaller space (e.g. instead of side-by-side panes we could have tabs).
2. Dedicated React component
This probably requires bigger refactoring but could also be the most flexible solution since it could be used outside of browser environments (e.g. Electron apps). The component would be close to the main component in
app.js
but provide more configuration options. There some open questions:Maybe the easier solution is to let the calling code pass the available parsers to the component. They would have to comply with our interface, but that shouldn't be too bad.
It would also be great if the calling code could add custom visualization / output panes (e.g. the transpiled code like in https://babeljs.io/repl/).