You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been enjoying 'database-first domain modelling', and also io-ts (having come across it here) (thanks).
Thinking about higher-order types, custom types, and type overrides #60 at the same time as defining io-ts schema has made me wonder if io-ts should generate runtime types (rather than static types) using io-ts. It would be strictly more powerful and not much more effort from the code generation side (actually it might be easierhttps://github.com/gcanti/io-ts-codegen).
You can still get hold of types by using t.TypeOf<typeof IoTsSchema> so we can just put that everywhere we'd currently put our existing types.
This allows dependees not only to check their code for type agreement but also to parse inputs that are related to database-defined schema (as they surely must be). This could allow the DB schema to be the statically typed centre of a system. Inputs can be typed at run-time and compile-time from schema derived from the DB.
I think io-ts will be much better than the inchoate type system I added for enums for transporting type information around for composite types. And I can't entirely put my finger on why yet, but I think using runtime types at generation time and in generated code (as well as to carry the database type mapping) is going to unlock some powerful features.
The text was updated successfully, but these errors were encountered:
silasdavis
changed the title
Generate runtime types with io-ts
[Idea] Generate runtime types with io-ts
Jun 7, 2020
I have been enjoying 'database-first domain modelling', and also
io-ts
(having come across it here) (thanks).Thinking about higher-order types, custom types, and type overrides #60 at the same time as defining io-ts schema has made me wonder if io-ts should generate runtime types (rather than static types) using io-ts. It would be strictly more powerful and not much more effort from the code generation side (actually it might be easier https://github.com/gcanti/io-ts-codegen).
You can still get hold of types by using
t.TypeOf<typeof IoTsSchema>
so we can just put that everywhere we'd currently put our existing types.This allows dependees not only to check their code for type agreement but also to parse inputs that are related to database-defined schema (as they surely must be). This could allow the DB schema to be the statically typed centre of a system. Inputs can be typed at run-time and compile-time from schema derived from the DB.
I think
io-ts
will be much better than the inchoate type system I added for enums for transporting type information around for composite types. And I can't entirely put my finger on why yet, but I think using runtime types at generation time and in generated code (as well as to carry the database type mapping) is going to unlock some powerful features.The text was updated successfully, but these errors were encountered: