Closed object closed 4 years ago
I'm not sure if there is a good way to make it with the code as it is today, but it shouldn't be difficult because in the end Bridge acts as a subscription. I can probably expose it as a subscription and then it could be easily used inside a Cmd.ofSub
.
That would be great because as of today the configuraton API gives an impression of being resolved once on startup. So exposing it as a subscription will make it simple to hook to an asynchronously resolved configuration settings.
Added a Bridge.asSubscription
taking the config on version 3.4.0. Can you test if it's working as expected?
Yes it works great, I can write code like this:
let bridgeSubscription (state : State) =
Bridge.endpoint state.AppSettings.SocketUrl
|> Bridge.withUrlMode Raw
|> Bridge.withMapping (fun x -> x |> MediaSetEvent)
|> Bridge.asSubscription
and send it to Cmd.OfSub, and everything works fine. Thanks a lot!
A client app startup code looks like this:
And for more advanced configuration I can use Calculated URL mode with a function that returns a url for socket communication.
But in both cases the url is resolved upfront. What if the configuration comes from an app settings JSON? Then the app typically introduces app settings load messages (e.g. LoadAppSettings and AppSettingsLoaded) and loads the settings asynchronously. The regular operations are deferred until app settings are loaded and the configuration is resolved.
It would be nice to be able to fit Bridge configuratoin into the same workflow i.e. defer setting up Bridge config URL resolution until the application settings are loaded. But it doesn't seem to be possible using withBridgeConfig. Or am I overlooking something?