Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Matt Thornton
    @Choc13
    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
    Matt Thornton
    @Choc13
    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.
    Maxime Mangel
    @MangelMaxime

    If you use Feliz, you can also use [<ReactComponent>] to transform almost any F# function into a ReactComponent:

    https://zaid-ajaj.github.io/Feliz/#/Feliz/ReactApiSupport

    Aistis Raulinaitis
    @sheganinans
    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
    Aistis Raulinaitis
    @sheganinans
    finally! got it working:
    [<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) ] ]
    Matt Thornton
    @Choc13
    Ah nice. Yeah was wondering where the useRef call was in the first 👍
    Aistis Raulinaitis
    @sheganinans
    well, i thought you could get away with useCallback, but i guess i misunderstand how it works
    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
    Matt Thornton
    @Choc13
    You probably don’t need the useState or useEffect thinking about it
    Aistis Raulinaitis
    @sheganinans
    oh really?
    id be very interested in seeing how that would work
    Matt Thornton
    @Choc13
    You can just move that code in the useEffect outside of it and check if the ref is Some ref and then read the objects width
    Because that state is purely derived from the ref.
    So you don’t have any side effects there
    Aistis Raulinaitis
    @sheganinans
    yeah, i suppose id pass in the ref into the view
    ok, great, this gives me a good path forward
    Matt Thornton
    @Choc13
    👍
    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
    Aistis Raulinaitis
    @sheganinans
    in the example i gave, i cant take it off, but in other cases, im sure thats true
    if i take it off, id need an annotation in the Some branch of the match
    Matt Thornton
    @Choc13
    Ah right fair
    Swings and roundabouts then I guess.
    Aistis Raulinaitis
    @sheganinans
    yeah, thats left to right typechecking for you :)
    Matt Thornton
    @Choc13
    🤓
    Aistis Raulinaitis
    @sheganinans
    hahaha
    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
    Matt Thornton
    @Choc13
    Nice. Time to go clean up that tech debt then 👍
    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.
    Aistis Raulinaitis
    @sheganinans
    libraries and windows support
    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
    Aistis Raulinaitis
    @sheganinans
    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
    Aistis Raulinaitis
    @sheganinans
    like the perennial question of pipes vs conduit vs machines vs streams, lol
    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
    Aistis Raulinaitis
    @sheganinans
    plus a bunch of haskellers worked on f#, including SPJ himself, so it cant be that bad of a lang :)
    Matt Thornton
    @Choc13
    Yeah all good points. Just always curious to hear why other people have chosen the lang