Feliz.Router.BasePath stopped navigation

[SCullman]

After a dotnet paket update I noticed that navigation with Feliz.Router.BasePath stopped working, or better, the hook stopped setting a new state with the current page.

I was able to track it down to Fable.Promise 3.1. When I downgraded to 2.2.2, it worked again.

I still have no idea what is happening, and whether Feliz.Router or the React.useElmish hook is also affected.

[alfonsogarciacaro]

I guess it's difficult/not possible to provide some code to reproduce. This is strange, the only use of Fable.Promise I can see in all the dependencies of Feliz.Router.BasePath is this call to Promise.start in Feliz.UseElmish. It's true we've have changed the code emitted for Promise.start in 3.1 from $0 to void $0. This should be more correct because the signature of the function returns unit but maybe Feliz.UseElmish depended on this somehow?

[alfonsogarciacaro]

It would be good to know if other projects using Feliz.UseElmish are having issues after upgrading to Fable.Promise 3.1.

[SCullman]

@alfonsogarciacaro, I know my description was not helpful for further investigation. I was already happy to determine Promise as the cause since no error or warning came up during compilation.

[SCullman]

"UseElmish" counter works fine with Fable.Promise 3.1

[SCullman]

...and Feliz.Router has no dependency on Fable.Promise.

[TWith2Sugars]

I'm getting the same issue and I think I've narrowed it down to Feliz.UseElmish when the update function returns a state AND another Cmd that isn't Cmd.none. It seems that the returned Cmd isn't processed until something else triggers the update. I'll keep digging to pin it down.

[alfonsogarciacaro]

Thanks for that @TWith2Sugars! Would you happen to have some code you can share? I could try to compile and see if there's something out of place in the generated JS.

[TWith2Sugars]

I do but it's part of a rather large private project, let me try and distill it to something smaller.

[TWith2Sugars]

Right, I've managed to create a repo from the Feliz template and isolate the issue:

https://github.com/TWith2Sugars/FelizPromiseIssue

I've taken the counter example and add an extra Msg IncrementAgain
https://github.com/TWith2Sugars/FelizPromiseIssue/blob/main/src/Main.fs#L10

The update function will increment the state and return a Cmd.ofMsg Increment
https://github.com/TWith2Sugars/FelizPromiseIssue/blob/main/src/Main.fs#L20

When you hit IncrementAgain you'll see the state only increases by 1.

[TWith2Sugars]

Let me know if there is anything else I can do to help.

[alfonsogarciacaro]

Thanks a lot for this @TWith2Sugars! This is super helpful. By testing your repo I realized the reason of the different behaviour was the change in the Run method of the promise CE. If I go back to the previous code, IncrementAgain works.

...However, I'm unsure if going back is the right thing to do for Fable.Promise. Actually after investigating I concluded I was actually using an implementation of Delay/Run that may not be a good fit for JS promises. See #25

TBH, even after spotting the code that's causing the wrong behaviour I still don't know what's actually happening. It's difficult to follow the program flow in UseElmish because it uses multiple React hooks. My intuition is that UseElmish somehow "relied" on a quirk of the previous Fable.Promise implementation. For example, if I replace promise with async here, the problem is still happening:

let rec dispatch (msg: 'Msg) =
    async {
        let mutable nextMsg = Some msg

        while nextMsg.IsSome && not (token.current.IsCancellationRequested) do
            let msg = nextMsg.Value
            let (state', cmd') = update msg state.current
            cmd' |> List.iter (fun sub -> sub dispatch)
            nextMsg <- ring.current.Pop()
            state.current <- state'
            setChildState()
    }
    |> Async.StartImmediate

It'd be ideal if the issue could be solved on the UseElmish side (if we cannot get a failing test for Fable.Promise). I came up with a draft alternative implementation (that's missing things and can definitely be improved) that doesn't use async/promise (as the original Elmish) and it's working:

static member useElmish<'State,'Msg> (init: 'State * Cmd<'Msg>, update: 'Msg -> 'State -> 'State * Cmd<'Msg>, dependencies: obj[]) =
    let exec dispatch cmd =
        cmd |> List.iter (fun call -> call dispatch)

    let setStateRef = React.useRef(ignore)
    let initState, initCmd, dispatch = React.useMemo(fun () ->
        let initState, initCmd = init
        let rb = RingBuffer(10)
        let mutable reentered = false
        let mutable state = initState

        let rec dispatch msg =
            if reentered then
                rb.Push msg
            else
                reentered <- true
                let mutable nextMsg = Some msg

                while Option.isSome nextMsg do
                    let msg = nextMsg.Value
                    let (model', cmd') = update msg state
                    setStateRef.current model'
                    cmd' |> exec dispatch
                    state <- model'
                    nextMsg <- rb.Pop()

                reentered <- false

        initState, initCmd, dispatch            
    )

    let state, setState = React.useState(initState)
    setStateRef.current <- setState

    React.useEffect((fun () ->
        initCmd |> exec dispatch
        React.createDisposable(fun () ->
            getDisposable state
            |> Option.iter (fun o -> o.Dispose())
        )
    ), [||])

    (state, dispatch)

@Shmew @Zaid-Ajaj @MangelMaxime

[MangelMaxime]

Hello @alfonsogarciacaro,

I am currently working for a client who is using Feliz.UseElmish and was wondering why it is using a custom implementation instead of asking for the standard Program used in Elmish?

My reason is that by not using Program we are losing a lot of stuff like the capability to compose/augment the Program to add new functionality.

Also the Elmish Program has been tested and working since a long time so we would also benefit from that part.

Wouldn't it make sense to try using Elmish Program instead of a custom implementation ?

[TWith2Sugars]

I've tested those replacements in my larger app and it's resolved all of my issues 👍

[SCullman]

@alfonsogarciacaro, this would also fix the initial issue, routing would work again.

@MangelMaxime, I used to work with Elmish Program , but Feliz.useElmish simplifies a lot, if not any of my projects.
Hooks like React.useState() or React.useDeferred() are good enough for navigation and basic initialisation with data. And when a ReactComponent requires more logic, useElmish() still can step in.