Calling Navigation.newUrl from the init user function does not trigger a call to urlUpdate

[mlaily]

Description

From what I could see, urlUpdate is automatically called whenever a navigation even occurs, like one triggered by a call to Navigation.newUrl.

This is not the case when calling Navigation.newUrl from the user init function though.

From what I could see, this seems to be due to the fact subscriptions are initialized after the init function is called, so the browser navigation event goes unnoticed (the onLocationChange handler supposed to intercept it is not setup yet).

This is inconvenient because it means trying to do a url redirection when the app starts does not work as expected (the browser url will change, but will be out of sync with the model).

It might be a known issue/shortcoming, but I could not find documentation on this so I'm opening this issue.

Workaround

A simple workaround is to create a user message (e.g. DelayedRedirectIndexPage), and use it from the init function instead of calling Navigation.newUrl.

Then in the update function, handle the DelayedRedirectIndexPage message and do the call to Navigation.newUrl there.

Doing it that way ensures the onLocationChange subscription of Elmish.Navigation is setup when the navigation event is triggered.

Related information

• elmish version: 4.0.2 (latest)
• fable-compiler version: 4.1.4
• fable-core version: 4.1

[MangelMaxime]

From what I could see, this seems to be due to the fact subscriptions are initialized after the init function is called, so the browser navigation event goes unnoticed (the onLocationChange handler supposed to intercept it is not setup yet).

I think that you are right that init is called before the subscriptions are attached but Navigation.newUrl is not called directly because this a command.

Looking at the code it seems like the execution order is:

1. Call init
2. Call subscribe
3. Execute the cmd coming from init in your case Navigation.newUrl
4. Compute (register) subscription ?
5. Start the loop which process messages indefinitely

Could it be that 3 and 4 needs to swap?

I am not all that familiar with the new subscription system of Elmish so all I am saying are things to investigate.

Also, would you have a reproduction code/project that we could use and check for the bug?

[et1975]

The fix is released as Elmish@4.1.0, please give it a spin.

[mlaily]

@et1975 tested and my scenario works out of the box now. Thanks a lot! ♥