Any support about ngx-grpc HOT 6 CLOSED

that's all I need to know, will give it a shot. Switching on URL is fine as that is what we do atm with the protoc js output.

from ngx-grpc.

Hi @owenhaynes

mostly it should be supported, what's missing is a binding between message and its URL. The primary problem in implementing this in web is the fact that one needs to have all possible messages preloaded, which will hit the performance of the web application. I have some thoughts on that, e.g. having some map with native browser imports (like angular router lazily loads the child route modules), however this also has limitations.

So, what should already be possible: if you know what are the incoming messages then you can have a switch on the URL and

• deserialize the messages from the Uint8Array with MyMessage.deserializeBinary
• serialize with msgInstance. serializeBinary() and pack it back with a proper URL

Mostly, if this functions (I did not try but it should), then one can say any is by 90% supported.

from ngx-grpc.

Super, please let me know if everything works as expected

from ngx-grpc.

Have the Any type compiling still need to test the service we use.

Could be helpful if GrpcMessage had the deserialize method so that could create better templated code around Any.

Would be also useful if the well known types was static within ngrx-grpc so that fake placeholder don't have to be used to generate them e.g StringValue

from ngx-grpc.

Could be helpful if GrpcMessage had the deserialize method so that could create better templated code around Any.

Could you give an example (pseudo-code) what you mean?

Would be also useful if the well known types was static within ngrx-grpc so that fake placeholder don't have to be used to generate them e.g StringValue

This was already proposed, the question is whether you can win something from that. Yes, slightly more files get generated, but nothing would really get changed if they move to a separate library... I mean, regardless of where they would come from, the final application will include the same code

from ngx-grpc.

Ignore the first part, came up with a better solution to my problem.

For the types thing yes I think there is a win

1. you had a library foo it had messages using google.StringValue and then had a package called bar which also used google.StringValue in messages and you had some mapping code these would be different types as they are in different namespaces as you would have if I am correct
   foo/google/wrapppers.pb#StringValue
   bar/google/wrapppers.pb#StringValue
   sure typescript would complain at this.

2. To have definitions ready for google.Any support with well known types you would have to some how get them generated. E.g a place holder message or manually generate them.

3. Helpers to work with these types. <-- this one is more a nice to have, but you know better code for google.Timestamp

from ngx-grpc.