Not compatible with Thoth.Json 3-beta

[0x53A]

Thoth.Json 3 is currently in beta.

When I tried to use Thoth.Json 3.0.0-beta-002 with Elmish.Bridge.Client 2.0.1, I got this error:

ERROR in ./.fable/Elmish.Bridge.Client.2.0.1/Library.fs
Module Error (from ./node_modules/fable-loader/index.js):
c:/Projekte/ebos/ebosYC/.fable/Elmish.Bridge.Client.2.0.1/Library.fs(106,18): (106,97) error FABLE: Cannot get type info of generic parameter Server, please inline or inject a type resolver
 @ ./src/Client/App.fs 19:0-471 134:14-71 134:72-111 134:141-179 136:3-41 136:46-53 138:4-39
 @ ./src/Client/Client.fsproj
 @ multi ./src/Client/Client.fsproj ./src/Client/site.css

ERROR in ./.fable/Elmish.Bridge.Client.2.0.1/Library.fs
Module Error (from ./node_modules/fable-loader/index.js):
c:/Projekte/ebos/ebosYC/.fable/Elmish.Bridge.Client.2.0.1/Library.fs(97,23): (97,102) error FABLE: Cannot get type info of generic parameter Server, please inline or inject a type resolver
 @ ./src/Client/App.fs 19:0-471 134:14-71 134:72-111 134:141-179 136:3-41 136:46-53 138:4-39
 @ ./src/Client/Client.fsproj
 @ multi ./src/Client/Client.fsproj ./src/Client/site.css

[Nhowka]

I was thinking about changing the serializer to the same as Fable.Remoting as it seems to be working ok for the same use case. I hope the bundle size won't get out of control, because the changelog of Thoth says that it should have better bundle size with that new version.

I'll do some tests. Thanks for letting me know!

[0x53A]

One issue I had with the Remoting serializer is that it doesn't allow you to inject serializers for your own classes.

That means anything except built-ins, tuples, unions, records, doesn't work.

I haven't looked too deep into it, but theoretically, the extra/custom serializers might solve this for Thoth.

On the other hand, I doubt this is really a common scenario for Elmish.Bridge, 99.99% of the time you probably just want to exchange a small union type.

[Nhowka]

I uploaded a version using the same serializer as Remoting with a small tweak that check the base server union type and auto register every type used inside it if there is no ambiguity. But yes, the recommended scenario is to exchange the messages as an union type.

[Nhowka]

I added a crude custom serializer support on the pre2 version. The support now is just for the messages the client sends and the server receives. As the server only sends a specific type to the client, maybe that should be enough.

[OnurGumus]

Actually there is a problem with the custom deserializer as it requires converion to exact server message. What if I have something like type String50 = private String50 of string. Then it just doesn't work.