OvermindDL1 / bucklescript-tea

TEA for Bucklescript

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

typed html properties

IwanKaramazow opened this issue · comments

commented

In Elm properties of html tags are defined as a list.

profile user =
    div [ class "profile" ]
      [ img [ src user.picture ] []
      , span [] [ text user.name ]
      ]

=> class "profile", src user.picture etc.

I'm wondering if we can fully type those properties instead of using a list with:

(* bs.obj can also be used as an attribute in external declarations, as below: *)

external make_config : hi:int -> lo:int -> unit -> t = "" [@@bs.obj]
let v = make_config ~hi:2 ~lo:3

(* compiles down to *)
(* var u = {hi : 3} *)
(* var v = {hi : 3 , lo: 2} *)

Or I am overseeing something here?

I'm actually playing with precisely that idea for various enhanced API's for it. :-)

For the most basic 'TEA' layer I want to emulate how Elm does it as much as possible.

Sadly the Elm style is really allocation-heavy, when it really does not need to be (although its already one of the fastest out so not much reason for it to optimize it I guess). There will be alternative methods coming that will be more efficient, but discussion is definitely encouraged. :-)

OCaml's typing system is significantly more powerful than Elm's, we could pretty easily make something that builds up to pretty easy and direct DOM calls with minimal allocations, but it will involve breaking the hard Elm API, hence why it will be side modules in this project. :-)

But yes, there are many many ways it can be expanded, and they are all in planning as per https://github.com/OvermindDL1/bucklescript-tea/blob/master/README.md#description so if you have any great ideas for interfaces, code, etc., then please do share. :-)

commented

I'm wondering if the Elm api could handle graph-like data, if you're conceptually walking through a cycle. You want different "views" of a node in this case, i.e. the fields of a node your view can access. Do you just dump a type with all the fields down into a function, which 'restricts' the fields at the UI level? If you take a look a Facebook's Relay, it restricts the fields a component can access, it's not like you just don't display some fields of a node.

Yeah the overall design is hard to come up with because there are *so*many*options*... >.>

this bug has a discussion of using tyxml with bucklescript: rescript-lang/rescript-compiler#162