For the purpose of discussion first of all, this is a proof of concept of one approach to add support for automatic conversion of a select few native types to their js equivalents for props on external component definitions (as briefly discussed here).
The currently implemented conversions are:
string -> Js.js_string Js.t
bool -> bool Js.t
'a array -> 'a Js.js_array Js.t where 'a will also be recursively converted
React.element list -> React.element Js.js_array Js.t (in order for JSX children to work as expected, unsure if it should convert lists in general)
Everything else will be passed on as-is, which means you can still use Js.js_string Js.t directly, for example, and have it work as expected.
Beware, however, that this is just a syntactic rewrite. It doesn't actually know what the types are, so if they're aliased, shadowed or qualified in some unexpected way, this will break. It's very unlikely that this will happen with such fundamental types though. And in most cases you should get reasonable errors. Because the wrapping is done using non-polymorphic functions it will tell you exactly what it expects. The cases where it doesn't is if you expect conversion, but it doesn't, since then it'll just pass the value on to JavaScript where it will result in strange things happening, as is the norm over in untyped JS-land.
For the purpose of discussion first of all, this is a proof of concept of one approach to add support for automatic conversion of a select few native types to their js equivalents for props on external component definitions (as briefly discussed here).
The currently implemented conversions are:
string->Js.js_string Js.tbool->bool Js.t'a array->'a Js.js_array Js.twhere'awill also be recursively convertedReact.element list->React.element Js.js_array Js.t(in order for JSX children to work as expected, unsure if it should convert lists in general)Everything else will be passed on as-is, which means you can still use
Js.js_string Js.tdirectly, for example, and have it work as expected.Beware, however, that this is just a syntactic rewrite. It doesn't actually know what the types are, so if they're aliased, shadowed or qualified in some unexpected way, this will break. It's very unlikely that this will happen with such fundamental types though. And in most cases you should get reasonable errors. Because the wrapping is done using non-polymorphic functions it will tell you exactly what it expects. The cases where it doesn't is if you expect conversion, but it doesn't, since then it'll just pass the value on to JavaScript where it will result in strange things happening, as is the norm over in untyped JS-land.