The library consists of two parts: a set of types generated from the schema, and some functions that set up a websocket connection and handle things like reception statuses. It might be better to move the generated code to a second crate, and re-export the types in the main crate.
This was prompted by the fact that typify now generates error types (for e.g. conversion errors) in an error module, and it might be nice to place our own errors (S2ConnectionError) next to the generated errors. But that's difficult in the current architecture - combining generated and handwritten code nicely is tricky. Splitting the generated code off to its own crate should help with this, also for future cases where we want to present handwritten and generated code side-by-side.
The library consists of two parts: a set of types generated from the schema, and some functions that set up a websocket connection and handle things like reception statuses. It might be better to move the generated code to a second crate, and re-export the types in the main crate.
This was prompted by the fact that
typifynow generates error types (for e.g. conversion errors) in anerrormodule, and it might be nice to place our own errors (S2ConnectionError) next to the generated errors. But that's difficult in the current architecture - combining generated and handwritten code nicely is tricky. Splitting the generated code off to its own crate should help with this, also for future cases where we want to present handwritten and generated code side-by-side.