Ah right yeah, you need to use something like
FunctionComponent.Of from React.Fable. There’s a section in this blog post about how to do the same thing with Feliz. The relevant bit is this code:let view =
React.functionComponent(fun {props} ->
let (currentState, setState) = React.useState({initial state})
{view code}
)
Oh apparently it’s now a
[<ReactComponent>] attribute in Feliz 3
And this Fable blog post has some good information on why we need this in Fable when we don’t seem to need it with JSX.
This Fable blog post has some more information on why we need this here and not in JSX.
If you use Feliz, you can also use [<ReactComponent>] to transform almost any F# function into a ReactComponent:
ok, so this is what ive come up with, but its still not working:
[<ReactComponent>]
let useWidth () =
let (w, setW) = React.useState 0.
let ref =
React.useCallback (fun (node : Browser.Types.Element) ->
if not (isNull node) then setW node.clientWidth)
w, ref
[<ReactComponent>]
let tv () =
let (w, r) = useWidth ()
Html.div [
Html.span [
prop.ref r
prop.text "xxxxxx"
]
Html.br []
Html.span [
prop.text (string w)
]
]
its says that w in the second component is undefined
[<ReactComponent>]
let tv () =
let r = React.useRef (None : Browser.Types.HTMLElement option)
let (w, setW) = React.useState 0.
React.useEffect (fun () ->
match r.current with
| None -> ()
| Some c -> setW c.offsetWidth)
Html.div [
Html.span [
prop.ref r
prop.text "xxxxxxx" ]
Html.br []
Html.span [
prop.text (string w) ] ]
now i just need to figure out how to do this for multiple objects in a composable way :) at least the interop weirdness is mostly solved
id be very interested in seeing how that would work
Because that state is purely derived from the ref.
So you don’t have any side effects there
ok, great, this gives me a good path forward
Minor one but you might not need the type annotation on the None in the useRef call. I think it can be inferred from the usage in prop.ref and the useRef function itself
if i take it off, id need an annotation in the
Some branch of the match
Swings and roundabouts then I guess.
i dont miss bi-directional checking too much (ala haskell and others), but sometimes its really nice
F# overtook Haskell and Rust as my favorite language about 4 years ago, lol
hmm now that i know about the existence of useState and useRef, that would have made some code i wrote a while back much much cleaner :)
i guess thats what happens when you use a framework, but dont know much about the underlying framework it builds on top, lol
What gives F# the edge in your opinion? Particularly over Haskell as I guess that’s a fairer comparison to make in terms of the space they both occupy on the abstraction (from the hardware) spectrum.
i have over the years done more and more windows stuff
and f# is just such a pleasant language to use, especially type providers, easy mutability, etc... but ofc im preaching to the choir here
i use f# plenty on linux and have replaced it as my language of choice over haskell... although there are some things that draw me back to haskell, but im happy with f#
the biggest thing i miss in F# is HKT, but i understand why they wont be included in the language, and thats fine, since there are plenty of things that i get from using F# over haskell
although haskell's windows support got a massive improvement this recent release, whole new IO manager
still, if you're developing an application that is expected to be interfacing with a lot of .net code and runs on windows, f# is still the better choice over hakell, even with the recent improvements
ive been looking for a language for a long time that lets me go from "prototype to production" in one language.. and i think F# is pretty much the best at it.. i tend to do a lot of statistics so i tend to be CPU bound a lot, and haskell being a lazy language can allocate a lot of stuff for you, even if you dont ask for it... making productizing it a bit more difficult.. rust on the other hand is great for being able to take advantage of it's free-at-runtime abstractions, but as most know that comes at the cost of complexity in the language and a lack of speed at the prototyping phase
if you stick through taming laziness and are good at sifting through the ecosystem, then haskell can definitely serve as a good platform for an application. but f# sort of obviates both of those concerns, you only use laziness when you need it and either there is a library in C# for what you want, sometimes a wrapper of it for f#, and very rarely you might have to do it yourself if youre doing something really niche. with haskell, knowing which library to use, if there is one, is sometimes a bit nuanced
all streaming abstractions, all work together, all have different focuses
f# just has
Seq, lol it either works for your usecase or it doesnt. thats if youre ignoring Observable, and PSeq, and others, but you know what i mean
there is certainly a lower complexity curve for F# for going from "prototype to production", to take a rubyism, there is more convention over configuration in the F# community than there is in haskell