mangelmaxime/elmish.canvas

Fulma minimal template

This template setup a minimal application using Fable, Elmish and Fulma.

How to use ?

Architecture

• Entry point of your application is src/App.fs
• We are using hmtl-webpack-plugin to make src/index.html the entry point of the website
• Entry point of your style is src/scss/main.scss
  • Bulma and Font Awesome are already included
  • We are supporting both scss and sass (by default we use scss)
• Static assets (favicon, images, etc.) should be placed in the static folder

In development mode

If you are using Windows replace ./fake.sh by fake.cmd

1. Run: ./fake.sh build -t Watch
2. Go to http://localhost:8080/

On Unix you may need to run chmod a+x fake.sh

In development mode, we activate:

• Hot Module Replacement, modify your code and see the change on the fly
• Redux debugger, allow you to debug each message in your application using Redux dev tool

Build for production

If you are using Windows replace ./fake.sh by fake.cmd

1. Run: ./fake.sh build
2. All the files needed for deployment are under the output folder.

elmish.canvas's Issues

Needs update?

I'm having a hard time getting this to build (macos). I've started looking into what might be wrong, and these are two things I see immediately:

• Mouse.fs missing according to elmish_demos.fsproj
• [<Pojo>] seems to have just disappeared from Fable, despite being mentioned in a few online tutorials. I'm assuming it became obsolete (?)

@MangelMaxime I see you do lots of wonderful things with Fable; if you're still active I'd appreciate you checking this project out and seeing if at least from your point of view it's up to date with latest Fable ecosystem.

Many thanks

Questions, not issues: Conditionals / drawOps vs drawUsingContext / latest thinking

Hi, I appreciate this was an experiment, but I'm interested in using this or something like it. I have a couple of questions regarding your thoughts on design. I'm experienced with C#/C/C++/JS, but relatively new to F#, for context.

• The list of drawops is very functional, and has that pure (monadic) feel. However, even accepting that it's not a complete implementation, how would they encode constructs like conditionals, loops etc. For example, in JS

if (someBool) ctx.DrawRect(..) else ctx.DrawEllipse();
while (i < n) ctx.DrawRect(i*10, ...)

Are you expecting the user to instead do (I just thought of this):

let genDrawOps : DrawOp list =
     let mutable ops = [| |]
     if someBool then ops.Append( Rect x y w h ) else ops.Append( Ellipse ... )
     ops.AppendRange( [1..n] |> Arrap.map (fun i -> Rect (i*10) 0 10 10) )  )
     ops

I think I answered my own question :-)

• Would having an alternative to the drawOps property, such as an imperative effectful drawUsingContext be a useful addition? drawOps would ultimately be handled by the default drawUsingContext. So, indirecting the call from react_canvas.js to Canvas.drawOps via a function in the component props. I see from another issue there is concern about the GC pressure from the drawOps array. Would this side-step the issue? The other discussion also seemed to be happy with imperative-style drawing handlers. Eg

   drawNow() {
         const drawFn = this.props.draw ? this.props.draw : Canvas.drawOps
         drawFn( this.getContext(), this.props ) ; // Rework drawOps fn to index into drawOps array
   }

   componentDidUpdate() {
         this.drawNow();
    }

• Lastly, given that it's been 2 years and we have a new Fable (v3), etc, is there any change in your thinking about how to integrate HTML Canvas with Elmish? For me, I would like an overall Elmish UI, but with a canvas that I can render to (performantly, and simply). This is the closest project that I can see!

Thank you

Prevent too many allocations

The API with the DrawOp union type is very nice, but it has one little problem: it's creating too many allocations. For example, Particle.draw in the Segments demo is running every frame and allocates the memory for the lists and one union type for each draw operation. For this sample is fine, but it may cause problems in more complex scenarios.

I can only think of two possible solutions at the moment:

• Force that the draw operations are calculated only once and then evaluated every frame: however, this may be difficult because of the way view functions work in Elmish.
• Offer an API that is just inline functions directly compiling to the draw instruction (wrapping everything in a function or a Lazy value to delay execution). This would probably be the most performant but the code would look quite imperative.

Animation is smooth at first but flickers when the mouse hovers on canvas

Hello there @MangelMaxime, very nice library you made, I wanted to play with a canvas in elmish for a long time.
Only I noticed that the animation of the sample becomes sluggish and starts to flicker once the mouse enters the canvas, if the mouse didn't enter the canvas, the default animation stays smooth. Did you notice that as well? I see this behavior both in Chrome and Edge

Implement Program.withCanvas

Implement Program.withCanvas for app that use only the canvas.

Example:

• Games
• Applications that needs control over their framerate