ToNavigable hides non-navigation message names from debugger

[IanWitham]

Description

Using toNavigable in the program initialization causes "wrapped" the underlying "message" names to be hidden from both the elmish-debugger and the console debugger.

toNavigable wraps the underlying message case in the Parser type. Elmish-debugger then uses reflection to get the event name, which resolves to the "wrapped" name instead.

Messages display in Redux Devtools inspector pane as one of either "Change" for a url change or "UserMsg" for anything else. I.e. the two Parser union cases from Elmish.Navigation.

This also effects the name shown in the console by "withConsoleTrace".

Repro code

Program.mkProgram init update view
|> Program.toNavigable (parseHash route) urlUpdate  // anything downstream of this gets wrapped message type.
#if DEBUG
|> Program.withConsoleTrace
#endif
|> Program.withReactBatched "elmish-app"
#if DEBUG
|> Program.withDebugger
#endif
|> Program.run

Expected and actual results

Expected result is that, when using Elmish.Navigation, original message names will still be displayed correctly in the Redux Devtools inspector panel. For example "Increment", "Decrement", "ModelLoaded".

Actual result is that, when using Elmish.Navigation, all non url-change messages are displayed in Redux Devtools inspector pane with the name "UserMsg".

Related information

• elmish version: 3.0.4
• fable-compiler version: 2.3.12
• fable-core version: 3.0
• Operating system: Windows 10

[MangelMaxime]

You can move the |> Program.withDebugger before the Program.toNavigable in order to not see the extra layer caused by Program.toNavigable.

You can also pin the property you want to explore in Redux dev tools.

We can't fix this issue because it's due to how program composition works. The same way that your top-level application msg hide the lower-level message.

For example, you see MainPage (SubComponen (LowerLevelMsg)) and not just LowerLevelMsg.

[IanWitham]

This means the "Change" messages aren't sent to the debugger which could be a problem if the urlUpdate function changes model state. However I think this is still an acceptable workaround if you fire a further command to change model state via the main update function instead. Thanks.