Exposing React APIs: hooks and components

[zaid-ajaj]

Exposing React APIs: hooks and components

[zanaptak]

Option 1 👍

What about React.functionComponent to get around the reserved word issue?

This library is already React-focused, i.e. using prop terminology, and React docs make a distinction between element and component with separate sections. I would find element more confusing personally.

Overloaded meaning of component isn't an issue with qualified use -- React.functionComponent would be unambiguous.

[cmeeren]

I'm leaning towards 1, but wouldn't a dedicated static type (not module) be better, to allow overloads like the rest of the Feliz API?

I've had to use this in Feliz.MaterialUI, see e.g. the Styles type with several overloads for Styles.makeStyles.

[cmeeren]

Also, do you plan on still depending on Fable.React or do you plan on creating custom wrappers? I'm asking because Feliz.MaterialUI currently depends on Fable.React stuff (e.g. IRefValue) transitively through Feliz, and if you plan on implementing your own React stuff in Feliz, then Feliz.MaterialUI should be updated to use that instead. And since it's a breaking change and Feliz.MaterialUI is not released yet, it's nice to know.

[Zaid-Ajaj]

but wouldn't a dedicated static type (not module) be better, to allow overloads like the rest of the Feliz API?

Indeed that's what I had in mind but I said module because I meant in the way you would access a function by fully qualifying the name React

do you plan on still depending on Fable.React or do you plan on creating custom wrappers?

Right now, I am thinking the only thing I want from Fable.React is ReactElement for compatibility with other applications and all existing third-party components, otherwise all existing and future third-party libraries would have to be (re)written with Feliz as a dependency if they were to work together which is a no-go if I want people to adopt this library one step at a time. As for React functions like hooks and components, I think I will write Feliz wrappers on top of them, then the implementation would be either a binding from scratch or fallback to Fable.React's if it makes sense

[MangelMaxime]

I am in favour of option 1 but I would prefer to use component because this is what you are creating.

For me, an element is really just the native DOM elements like div, etc. Also, using React terms would it easier for people to understand what's going on and searching documentation.

For the same reason, I would prefer to use Hooks.useState instead of React.useState the main problem being if people have both Fable.React and Feliz then Hooks.useState will depend on the open order.

[Zaid-Ajaj]

For me, an element is really just the native DOM elements like div, etc. Also, using React terms would it easier for people to understand what's going on and searching documentation.

I wanted to use "element" because I want users to think of as "just another element you can use in your render functions" there is no distinction between "native element" vs "component" there are only elements. Some "native elements" actually behave more like components such as input that has internal state but still it is just an element that can be used anywhere.

When you use React.element you are just creating an element with potentially some internalized state/behavior. Also it is a short word which encourages people to use it.

I like the word component too but it could mean A LOT of things and people might think it something that you are not supposed to do often but you actually should! Second con of the word is that it is preserved as a "future" F# keyword

For the same reason, I would prefer to use Hooks.useState instead of React.useState the main problem being if people have both Fable.React and Feliz then Hooks.useState will depend on the open order.

In javascript you do import { useState } from 'react', that is why I want to put in React without introducing many modules to look for things. Also it is highly unlikely that someone will open Feliz and Fable.React in the same module because they will quickly get name resolution conflicts when using style for some reason

[Zaid-Ajaj]

@zanaptak I like React.functionComponent, I guess you and @MangelMaxime are right, they are function components at the end of the day and the docs say so, I guess we can also have xml docs in the function that refers to the React docs

[Zaid-Ajaj]

This is looking really good:

Using React.functionComponent with React.useState:

open Feliz

let counter =
    React.functionComponent(fun () ->
        let (count, setCount) = React.useState(0)
        Html.div [
            Html.h1 count
            Html.button [
                prop.text "Increment"
                prop.onClick (fun _ -> setCount(count + 1))
            ]
        ]
    )

Replace MVU with built-in React.useReducer

module Reducers =
    type State = { Count : int }
    type Msg = Increment | Decrement

    let initialState = { Count = 0 }

    let update (state: State) = function
        | Increment -> { state with Count = state.Count + 1 }
        | Decrement -> { state with Count = state.Count - 1 }

    let counter = React.functionComponent("Counter", fun () ->
        let (state, dispatch) = React.useReducer(update, initialState)
        Html.div [
            Html.h3 state.Count
            Html.button [ prop.onClick (fun _ -> dispatch Increment); prop.text "Increment" ]
            Html.button [ prop.onClick (fun _ -> dispatch Decrement); prop.text "Decrement" ]
        ]
    )

Use React.useEffect:

let ticker =
    React.functionComponent("Ticker", fun (props: {| start: int |}) ->
        let (tick, setTick) = React.useState props.start
        React.useEffect(fun () ->
            let interval = setInterval (fun () ->
                printfn "Tick"
                setTick(tick + 1)) 1000
            // creates a disposable value
            React.createDisposable(fun () -> clearInterval(interval))
        ,prop.start) // re-evaluate hook when `props.start` changes

        Html.h1 tick
    )

// later
Html.fragment [ 
  ticker {| start = 0 |}
  ticker {| start = 5 |}
]

[cmeeren]

Looks great! Will there be an overload of functionComponent accepting some memo stuff, like Fable.React's FunctionComponent.Of? (I don't know if it's part of the native React API or not.)