v0.1.0

[solnic]

• Added Drops.Contract module for defining validation schemas with additional rules
• Added Drops.Validator module for running validation functions against input
• Added Drops.Validator.Messages.DefaultBackend that's configured by default in contracts
• Added Drops.Types module with the following built-in types:
  • Drops.Types.Type - basic type
  • Drops.Types.List - a list if member type
  • Drops.Types.Map - a map with typed keys
  • Drops.Types.Sum - a composition of two types
  • Drops.Types.Cast - a type that defines from-to casting types and caster options
• Added Drops.Predicates module which provides many common predicate functions like filled?, gt?, size? etc.
• Added Drops.Casters module which provides common type casting functions that can be used with the built-in types

---

This discussion was created from the release v0.1.0.

[kwando]

I played around with this for bit:

Feels good to use, and quite familiar if you have used the ruby version :)

I know this is version 0.1 and all of that but below is some of my initial and random thoughts

• the syntax for casting felt a bit odd to me at first
  string() |> cast(:integer, gt?: 10) would feel more natural instead of cast(:string) |> integer(gt?: 0)
• would love to see custom types, this is something I use quite often
• builtins for date, time, datetimes
• introspection API, the __schema__ functions in Ecto is quite useful to have
• share parts of a schema between modules? For instance I might want an address in 2 different schemas
• validate the params that is given to the schema macro, ofc I spelled :atomize wrong on my first try
• integration with Phoenix forms, maybe that shouldn't live in this project but it would be neat to use this with forms in Phoenix

One thing I really like with Ecto is that the abstraction is quite simple, custom validations is just another function you pipe your changeset through and it allows you to do more or less what you want with it. Makes it straighforwamd to compose logic.

I somehow would like to use an even more declarative API where the schema could be expressed as data:

%{
   name: {:string, :filled?},
   age: {:integer, gteq?: 0, optional: true},
   description: {MyMarkDownType, :filled?},
   tags: {{:list, {:string, :filled?},  :filled?}
}

Edit: Noticed there is already issues for a few my of bullet points :)

[solnic]

Thanks @kwando for taking the time to test it out and provide this great feedback!

Here are my comments:

- the syntax for casting felt a bit odd to me at first  
    `string() |> cast(:integer, gt?: 10)` would feel more natural instead of `cast(:string) |> integer(gt?: 0)`

This is interesting. Funny how 🧠 works! For me me the way it works now reads very naturally:

"cast a string into an integer" == cast(:string) |> integer()

This represents the flow too "try to cast to an integer" then "pass result to the type check predicate".

- would love to see custom types, this is something I use quite often

This is planned!

- builtins for date, time, datetimes

These types are already built-in when it comes to type-checks, casting is not fully supported though.

- introspection API, the `__schema__` functions in Ecto is quite useful to have

You can already inspect a schema via schema and schema/1 functions, unless you've seen it and it's not what you need?

- share parts of a schema between modules? For instance I might want an address in 2 different schemas

This is supported already. You can reference a defined schema in a compiled module via schema/1 function, and during definition you can reference schemas in the current module via @schemas variable, which is just a map with previously defined schemas. Here's a test with example usage.

- validate the params that is given to the `schema` macro, ofc I spelled `:atomize` wrong on my first try

This is planned. Will be done prior 1.0.

- integration with Phoenix forms, maybe that shouldn't live in this project but it would be neat to use this with forms in Phoenix

Both Phoenix and Ecto integrations are planned. I'll be adding all this stuff to future roadmaps :)

One thing I really like with Ecto is that the abstraction is quite simple, custom validations is just another function you pipe your changeset through and it allows you to do more or less what you want with it. Makes it straighforwamd to compose logic.

I really like it too, actually. The idea behind rules is the same though, they are being applied one after the other but in a type-safe manner. I decided to go with the rule DSL because it can simplify your life a bit, but at the end of the day it's just piping data through functions.

I somehow would like to use an even more declarative API where the schema could be expressed as data:

Yes, this is already how it works. Schemas are data. The DSL produces this:

%{
  {:optional, :name} => {:type, {:string, []}},
  {:required, :email} => {:type, {:string, []}}
}

This is a raw schema map, but I'm planning to have a better representation eventually so that schema conversations can be easily implemented. Just like in dry-schema, I'd like to be able to convert schemas into ie JSON Schema format.

[kwando]

Interresting! Looks like a missed few things in the docs, also a good hint that I should have peeked into the test suite to see more examples :)

I do understand the logic behind the casting (I think), maybe it is just something I have to get used  to :)

To me this cast(:string) |> integer() reads, "cast something to a string and then validate as an integer", but I guess it is because my brain translates that to something like input |> cast(:string) |> integer() 😅 .

With that mental model something like this input |> string() |> cast(:integer) makes more sense :D

I will play some more with this and get back to you if I struggle with something :)

[solnic]

To me this cast(:string) |> integer() reads, "cast something to a string and then validate as an integer",

Originally, I was thinking about something like from(:string) |> to(:integer) but this felt like too much, so I decided to stick to known vocabulary, which is cast :)

I want to keep the DSL functions as simple as possible, that's why we have two separate functions for defining cast input types and output types, connected with the pipe operator. I also want to underscore that I'm happy to reconsider this, I just need to hear more feedback from more people.