Enable Fable.Repl.Lib

[gitpod-io[bot]]

[MangelMaxime]

Hello @alfonsogarciacaro, that's a good news that libraries are coming back.

It would be nice if we could support the same set of libraries as before because, we put some effort to have nice example with them.

We can avoid adding all the Fulma example because they were more a repetition of Fable documentation but most of the Elmish, Thoth.Json, and React where crafted as comprehensible demos to help people learn Fable or give support for the most common problems.

List of the example we should re-add:

• Simple input -> Simple Elmish application
• Clock -> Show SVG manipulation
• Random User (Thoth) -> Show a "complex" application which use several libraries
• Speadsheet -> An impressive example which doesn't have a lot of line of code

Also do you think, if we could remove the inline limitation? I am asking because Feliz is quite popular nowdays and so it would be nice if we could support it too IHMO.

[alfonsogarciacaro]

Unfortunately it's going to be difficult to properly inlined functions from a precompiled lib. My original idea of serializing requires a lot of code changes, and if we recompile the full Fable.Repl.Lib on first run (as fable CLI does) the REPL is going to take much longer to bootstrap (and consume more memory). We could add back the hack from repl2 which was just to add an option to Fable to ignore the inline modifier (this usually works unless you're inlining to resolve generic info at compile time). But my current idea was to add Feliz.Engine.Snabbdom to the repl which doesn't use inlining and works well with Elmish. It's not the same API as Feliz but it's quite close and we could add a note saying "real" projects usually use Feliz/React instead.

It should be simple to port samples like the clock and todomvc to Feliz.Engine.Snabbdom. It should also be possible to add Thoth.Json/Fetch, though if we want to include the auto coders we'll need the Inject hack which I was trying to deprecate 😅

Funny enough, the spreadsheet sample was already in the REPL using the original Tomas Petricek implementation with its own custom Elmish and an (untyped) HTML DSL using virtual-dom.

[MangelMaxime]

It should also be possible to add Thoth.Json/Fetch, though if we want to include the auto coders we'll need the Inject hack which I was trying to deprecate sweat_smile

Surprisingly I am totally fine with not having the Auto coders in the REPL :trollface:

And to avoid unexpected bugs, we can add them being the #if !FABLE_REPL_LIB compiler directive so they doesn't show up on the auto complete.

if we recompile the full Fable.Repl.Lib on first run (as fable CLI does)

Can we compile package on demands? For example, a lot of REPL I see ask the user to select the dependencies they want to import in their REPL.

So in theory, it should be possible to either compile the dependencies when selected or make it more intelligent by support both compiling on the fly and precompiled dependencies.

But my current idea was to add Feliz.Engine.Snabbdom to the repl which doesn't use inlining and works well with Elmish. It's not the same API as Feliz but it's quite close and we could add a note saying "real" projects usually use Feliz/React instead.

Having a different API can make it harder for people to prototype etc. I see it a lot of time on Gitter/Slack channels. Because Feliz code is almost always the same everywhere, it should be possible to modify the files as a step of the CI to remove the inline from the member for example. Yes, the generated code would not be the same as Fable CLI but people would be able to copy/paste the F# code easily.

And also, only include the supported API. For example, I don't think the REPL support Fable plugins.