Serialization/Deserialization of Runtypes about runtypes

[pelotom]

I think I would prefer to keep it external to the core library.

[pelotom]

I must admit I don't fully understand the use case. The whole idea with runtypes is that they are constructed at the beginning of your app and have known types (thus they can be used to extract static types). So I don't understand why you'd want to serialize them. Can't your web worker code just construct runtypes itself, without the need to have them serialized? I guess I would need to see an example to understand better what you're trying to do.

[bradenhs]

That's actually what we're doing now. Both the non-worker and worker code import the same runtypes individually. It's definitely a feasible solution. The only drawback is that it takes a little more explicit wiring of things together to make it work this way. It makes the code a little more tightly coupled and a bit less DRY. Having the ability to pass arbitrary serialized runtypes to a worker would simplify things.... so it's not a deal breaker but would be nice. I totally get it if you don't feel that's a compelling enough use case to include serialization within the library.

[pelotom]

I would say it probably doesn't rise to the level of compelling to me, but I will also say that this sort of thing should be quite straightforward to do externally without changing the core library; that's what the Reflect type enables. See the show* function for an example of writing a function against the runtime Reflect information of a Runtype. Basically you could write a recursive serializer / deserializer against Reflect. The only caveat is that some runtypes, e.g. Constraint, are inherently unserializable because their Reflect information contains executable code in a closure, so the serializer should either throw or return a noop and print a warning if it encounters one of those.

* In case it's not clear, show is a function which takes a runtype and produces a string representation of it, so it's very similar to how a serialize function would work.

[bradenhs]

Thanks for the info! Depending on how things play out I may end up writing a serialize/deserialize function. If I do end up doing that would you consider a PR or would you prefer to keep serialization outside of the library?

[cdaringe]

Just came here for this! I think it could be very useful. Consider the case where schema is built up by composing schemas from multiple sources, programatically. Studying code is not a great mechanism then to get a "feel" for what the schema is. mySchema.toJSON() to allow for printing a nice representation could lend itself for sharing full schemas in a flat, easy to grok format.

[cdaringe]

ah, I see .show on the RT prototype is now a thing. will experiment with that