Closed pkese closed 3 years ago
I did some local tests and I hope it will fix it. I will upload the package to nuget now
Version 5.0.0-rc-5 uploaded. Can you check if it's working any different?
Unfortunately no, it still doesn't work.
It looks like Convert
serializes the message exactly the same way as Json.serialize
did.
This is the output of Bridge.withConsoleTrace
:
Remote message: ["Shared.Types.UpstreamMsg", "[\"UpstreamAppMsg\",[\"HwMsg\",[\"SwitchRelays\",{\"head\":[\"Pump1\",\"On\"],\"tail\":{\"head\":null}}]]]"]
I hope I'm not misleading you with the assumption that the deserializer on the server side expects the list to be formatted in a different way.
@Nhowka if the list was serialised like this it means that the type information was somehow missing during runtime or was resolved to obj in which case Json.serialize will fallback to the built in JSON.stringify. This is definitely not how the server expects the list to look like (with head and tail parts)
I updated my repo to include this bug reproduction: https://github.com/pkese/Elmish.Bridge.Test
@pkese Thanks for the repro! I looked at the generated code with @Zaid-Ajaj tip in mind and indeed it's losing the type information. I'll test the fix and upload a new package.
I believe that the package 5.0.0-rc-6 will work. The point free function composition to get the default serializer was being inferred as object. EDIT: Tested on your code and it was ok! 🥳
Yes. It works perfectly now. Thanks.
It appears that the new
Json.serialize
serializes F#'s Lists in a way that is incompatible with what the server expects.The other problem (besides messages not getting across) is that client simply gets disconnected and nobody reports any error, which makes it difficult to debug.