We've talked several times about componentizing the REPL. I've thinking of creating a different repo to host these core components. But given that we're already generating the FCS+Fable JS compilation here and we need some parts for other packages (like the metadata assemblies for fable-compiler-js) it's probably simpler if we generate the components here and pull them from other repos.
So the idea is to put here:
The fable-compiler/repl should pull these components and provide the rest of the UI and behavior. It will also be the base for other sites that embed the REPL, for example to create Markdown F# tutorials with result evaluation.
It shouldn't be too complicated to create the infrastructure but it's some work, I'll try to start next week, as I'm probably (the only?) person who knows how to fit all the pieces together ;)
cc @ncave @MangelMaxime @whitetigle @tpetricek
I am adding @Krzysztof-Cieslak in the discussion.
The React component for the Monaco editor for F# code.
Would be interested in this as well, I stole a lot of code to make Monaco work in AST viewer 😅. Although I wonder if makes more sense to have a Fable.Import.Monaco
sort of thing.
Please ping me when it's ready. I'd love to integrate Fable with Klipse to allow F# folks to write blog posts and tutorials with interactive code snippets.
This is complete :) Now assemblies necessary to compile F# projects with Fable are available in the fable-metadata
npm package, while FCS + Fable compiled to JS are being shipped in fable-standalone
, together with a web worker that can be embedded in a website.
Fable REPL already depends on these packages. Instructions are more or less like this:
fable-metadata/lib
and fable-standalone/dist
to wherever you're serving your static files: exampleFable.Standalone
and Fable.WebWorker
namespaces respectively):fable-standalone/src/Interfaces.fs
fable-Standalone/src/Worker/Shared.fs
Start the web worker with some info (most importantly where the metadata assemblies can be found).
Check the src/App/Main.fs file and see the worker messages to learn how to interact with the worker.
@alfonsogarciacaro This was an awesome rework and simplification of the repo! Can't wait for the blog post / tweet :)
Awesome work from all of you 🎉
@ncave But you don't have a Twitter account, or do you? ;) TBH, I'm somewhat concerned about making this too public because it's still not trivial to run the generated code and I'm afraid if people try to embed the REPL in their sites there will be many more issues to solve :/
@alfonsogarciacaro Of course I don't, that doesn't mean I don't follow ;)
I was just joking, whoever wants to know already (probably) knows from following you on GitHub.
Next step -> to the Moon! (I mean, F# projects in REPL, hint hint elbow jab ;)
@viebel The instructions to achieve that are in the comment above. I can help you to reduce them to calling an eval function (and probably an init function at the beginning) but please note without the webworker the user experience is not going to be nice because Klipse UI will freeze while the compiler is loading or compiling.
@alfonsogarciacaro I am not worried too much about the freezing of Klipse UI during compilation, assuming that it takes less than 300 msec for short code snippets.
Please help me reduce the instructions to a init + eval function call
Closing as we're not currently allocating resources into the REPL.
Most helpful comment
@alfonsogarciacaro Of course I don't, that doesn't mean I don't follow ;)
I was just joking, whoever wants to know already (probably) knows from following you on GitHub.
Next step -> to the Moon! (I mean, F# projects in REPL, hint hint elbow jab ;)