Feature request: allow full customization of URL search params and body serialization

[jedwards1211]

Describe the feature

I want to use devalue instead of superjson; devalue only provides a stringify method, not one that produces the transformed pre-stringified JSON.

I can work around this by wrapping the serialized string in an object, but that's a waste of bytes. Or I can just return a string anyway and suppress type errors, it does work but in either case the response body is an ugly quoted string. Or I could serialize to JSON.parse(devalue.stringify(data)) but that's a waste of CPU... apparently devalue.stringify builds the string directly for performance's sake so I'm not sure they're going to provide a serialize-to-object function.

Looking at the code, I guess this is so that oRPC can handle serializing to URL search params or body?

It would be nice if we have the option to provide separate serializers for URL search params and body so that we have full control of both and aren't faced with unhappy workarounds in a case like this.

Not saying I think the StandardRPCSerializer or StandardRPCLinkCodec interfaces need to be replaced, just that I wish we could extract lower-level interfaces that people can optionally use.

Additional information

• Would you be willing to help implement this feature?

[dinwwwh]

I think you can try implement your own link/handler like this: https://github.com/middleapi/orpc/blob/main/packages/client/src/adapters/fetch/rpc-link.ts

StandardRequest/Response allow you use new Blob(['any string here']) in the body so you can bypass the json-part

[dinwwwh]

How devalue speed compare with builtin orpc serializer? orpc builtin is really fast.

[jedwards1211]

I want a human readable serializer though so I can easily inspect things in the network tab. The docs say the builtin wire format is not human readable right? I took that to mean it's binary - or is it just a mangled json structure in text similar to SuperJSON and devalue?

As far as SuperJSON, I don't like that you have to globally register custom type serializers on it. Should be an option to stringify/parse like JSON or devalue supports.

[dinwwwh]

is it just a mangled json structure in text similar to SuperJSON and devalue?

JSON by default until we need binary format for something like File/Blob

[jedwards1211]

@unnoq it would be good to elaborate in the docs or add some small examples because I assumed "the protocol is [not] human-readable" along with supporting files/blobs meant the default protocol is binary, so I didn't even bother trying it out.

[jedwards1211]

Okay I see there are examples in https://orpc.dev/docs/advanced/rpc-protocol ...sorry, I was in a hurry, I never thought of "not human-readable" as a spectrum rather than yes or no

[jedwards1211]

I do still think it would be nice to have the option to customize URL search param serialization, because even if we're using a fully human-readable serialization like JSON.stringify, URL-encoding the JSON straight into search params isn't super nice to read. Right now, I guess going full OpenAPI is the only way to control that?

[dinwwwh]

You can use a Blob containing the output of devalue to control how the data is sent.