data_schema
data_schema copied to clipboard
Adzz
Declarative schemas for data transformations.
Currently the library is focused around emitting a Struct from some arbitrary input data. This is fine and good but the way we do that is with a `reduce`, which...
would there be any benefit to having schema fields live in persistent term rather than in a hidden module? I'm thinking about what absinthe does for example: https://hexdocs.pm/absinthe/Absinthe.Schema.PersistentTerm.html We are...
We should investigate how best to do this or if this is desireable / possible. Seems like we would have to implement something that implements the `Phoenix.HTML.FormData` protocol perhaps. Effectively...
Just an early thought but It would be great if you could easily generate either valid schemas, or valid input data that could be consumed by a schema. Even better...
When a cast function raises unexpectedly it can be tricky to see what field actually caused it. This can be helped by unit testing the cast fns (so you are...
currently it's a 0 arity fn which is good for like `Date.utc_today` but verbose for `[]` as it has to be `fn -> [] end` we can probably support both...
This can be done at compile time in the macro and will just validate that it hasn't been mistyped or anything.
It might be that the functions run too quickly for telemetry to be viable... But it could be good to be able to measure time taken to complete each cast...