Expose internal types

[altaic]

I'm writing a drawing app and I fortuitously discovered your wonderful library just when I started working on the graphics rendering.

My use case requires updating the BasicForms based on mouse movement, and it seems there isn't currently a way to get at them. It'd be great if you could expose the internal types, either in the current module or perhaps in a separate Graphics.Render.Internal module. Please correct me if I'm wrong, but I think my only other option would be to fork and maintain a separate repo.

Actually, I could track points myself and generate whole new Forms on each MouseMove message, but that would be a lot of crufty code and I worry about its performance.

Anyway, please let me know if you have any ideas I may not have considered or if you'd like me to write up a PR. Thanks for the great library!

[altaic]

I'm going to backpedal a bit. I think it'll be a bit easier and cleaner to keep my own list of Points and generate a new Form on every view. This also gives me a bit more freedom to control the UX while a shape is being drawn without getting hacky.

I'm still getting familiar with this library, though, so I'll have more comments regrading exposing some internal Graphics.Render stuff later.

[Kwarrtz]

I'm glad you find the library useful. I don't write toolkits often, but the lack of a high-level graphics library in Elm 0.17 seemed like a rather glaring problem.

As for the issue, would you mind elaborating on why exposing BasicForm would offer an advantage over the already existing functions for creating Forms? (i.e. shape, line, etc.) As far as I'm aware, those should be sufficient for creating any type of Form that you would want.

[altaic]

Tl;dr: they seem to be sufficient, thanks, though I worry about performance with real-time dependence on mouse move events.

I was hoping to manipulate parts of BacisForms so I didn't have to duplicate state in my app. The interactive nature of my app with respect to shape creation requires updating the Form in reaction to user input via mouse. For instance, while constructing a Polyline, a user clicks Points out. Each time the mouse moves, the line must be redrawn connecting the last Point in the List Point to the mouse's position. Initially I thought, "great, I'll just twiddle the state already in BasicForm and not worry about tracking that myself."

In retrospect, though, for other Forms and more complicated shapes, it became clear to me that I was "doing it wrong" and it's better if I keep track of my own Tools and List Points and regenerate the whole Form on each call to my view function. Yet, it's hard to predict performance or potential bugs arising from the torrent of mouse events that my app will have to handle-- some of it will be optimized away by Elm's (hopefully clever) handling of immutable data updates as well as VirtualDom diffing. I'll have a working prototype in a couple of days at most, so I'll know more about performance concerns soon.

[Kwarrtz]

Ah. I understand now. If you aren't already aware, Elm is based on a project called virtual-dom. In essence, virtual-dom takes too different DOMs and figures out the fastest way to get from one to the other. Elm uses this to update the DOM after each update event. Because of this, there should be no performance difference between modifying an already existing BasicForm and creating an entirely new one; immutable state and virtual-dom optimizations mean that the final JS for the two is exactly the same. Long story short, you shouldn't have to worry too much about performance problems :)

[altaic]

Thanks for the encouraging response! I'll go ahead and close this. If I have a concrete performance issue, I'll open a new one.