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

[mangelmaxime]

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

[MangelMaxime]

Hello @davedawkins,

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

F# has a feature called "comprehension list" which allows you to have "branching decision" in the list.

let test =
    [
        "See how"
        if true then
            "this line is shown"
        if false then
            "but not this line"
    ]

String.concat "\n" test |> printfn "%A"

REPL demo

I think it should works for the case you mentionned in point 1.

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

Yes, having an imperative code of just mapping/using the native JavaScript lowser the pressure on the GC.

This prototype version https://github.com/MangelMaxime/Elmish.Canvas/tree/feature/standalone_impl/src was doing much better.

It is not using Elmish at the moment, but the plan was to take inspiration from the Elmish loop system but plug it into an optimized "gameloop handler" that's why their is stuff like:

• begin -> elmish equivalent could be init
• update -> elmish equivalent could be update
• draw -> elmish equivalent could be view
• etc.

The missing part is input handling and I woud have written it has a module where you can read the current input state. By that, I mean the user would not subscribe to mouse event or keyboard event.

The system would take everything for them and they would just do if System.Mouse.IsJustPress ... or System.Keyboard.KeyDown "up" then ...

You can see an implementation of this system in my Hink experimentation:

Hink was a experimentation for creating Immediate an mode UI library in F#.

En excellente video explaining Immediate mode UI: https://caseymuratori.com/blog_0001
Or I made a talk presenting Hink and what Immediate mode UI is if you are curious : https://www.youtube.com/watch?v=mU6iuyf7o9g

Input systems of Hink: https://github.com/MangelMaxime/Hink/tree/master/src/Inputs

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!

Well, even when working on the prototype I discovered that using list would not work for performance reason. I guess, it could be a matter of having the standalone implementation done and wiring thing using a react component props if interaction is needed.

And also, communication from the "canvas" app to the "elmish app/parent" could be done using custom events.

I hope that I have kind of answer your questions.

[davedawkins]

I somehow missed this detailed reply - thank you!!