dry-rb/chat

WE MOVED TO ZULIP => https://dry-rb.zulipchat.com <=

Piotr Solnica

@solnic

ie {} is not the same as { email: nil } even though {}[:email] happily returns nil

but that’s just our wonderful ruby world :joy:

Andy Holland

@AMHOL

I guess if you validate, then send the data straight to the database, writing key-value pairs, it would make sense to validate the structure

Yeah :joy:

Piotr Solnica

@solnic

ok, I’ll figure something out

the data type we build is a hash with explicit schema (from dry-data)

it ignores unknown keys and handles only the ones you specified

so it’s gonna coerce what is needed

then it’s on the validation side to do what’s appropriate :)

Andy Holland

@AMHOL

Cool

Piotr Solnica

@solnic

https://github.com/dryrb/dry-validation/blob/dry-data-integration/spec/integration/schema_form_spec.rb

@AMHOL there we go ^

Andy Holland

@AMHOL

Nice, so that's separate for when you want coercion too?

Piotr Solnica

@solnic

yes

it still blindly symbolizes all keys, gotta work on that part now

maybe it’s not a bad idea to add key coercion to dry-data hash

Andy Holland

@AMHOL

Explicitly?

Piotr Solnica

@solnic

yes

Andy Holland

@AMHOL

Can't think of any reason not to

Piotr Solnica

@solnic

heh adding support for passing a block to predicates in the dsl was too easy, it’s a very good sign #happypanda

to make the dsl more concise I’m considering this now:

key(:address).hash? do |address|
  address.key(:age).int? { |value| value.gt?(18) }
end

@AMHOL WDYT? ^

Piotr Solnica

@solnic

this would be less trivial to implement though :)

Andy Holland

@AMHOL

As opposed to:

key(:address).hash? do |address|
  address.key(:age).int? & address.key(:age).gt?(18)
end

Piotr Solnica

@solnic

not exactly

type check is kind-of special

first of all you specify the expection for the type so we can infer coercion logic from it

secondly it’s the very first check that needs to be done before we can do anything else with the value

Andy Holland

@AMHOL

Ahh OK

Piotr Solnica

@solnic

so having it outside of the block would make sense

I dunno, will see, not gonna do that now, just wondering

Andy Holland

@AMHOL

So the predicate would be a pre-requisite to the validations running inside of the block?

Piotr Solnica

@solnic

yes

Andy Holland

@AMHOL

That makes sense :+1:

Piotr Solnica

@solnic

I just added support for passing blocks to predicate checks, which does the very same thing, but for type-check you get one more level of nesting

hence my thought about moving it to the outer block

Andy Holland

@AMHOL

Yep, that works for me

Piotr Solnica

@solnic

you can do value.int? & value.gt?(18) and the equivalent of this is using a block like this; value.int? { value.gt?(18) }

in general a block == AND

Andy Holland

@AMHOL

So it's like a normal AND where the right only evaluates if the left passes?

Piotr Solnica

@solnic

yes

Andy Holland

@AMHOL

:+1:

Andy Holland

@AMHOL

@solnic WDYT to removing the message processor from dry-validation?

Piotr Solnica

@solnic

@AMHOL dunno yet what to do with it tbh

Andy Holland

@AMHOL

@solnic I'll push what I've got so far, see what you think

Piotr Solnica

@solnic

@AMHOL sure

Andy Holland

@AMHOL

dryrb/dry-validation@cbc17e5

So the idea is that we can have a dry-validation-i18n gem for error messages

Where communities thrive

People

Repo info

Activity