dry-rb/chat

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

Andy Holland

@AMHOL

Hmm, it's an interesting one

Piotr Solnica

@solnic

it is

Andy Holland

@AMHOL

I guess we could validate the structure of the input too

Piotr Solnica

@solnic

I definitely do not want to make too many assumptions

yeah me too

Andy Holland

@AMHOL

Don't know whether that adds any value though

Piotr Solnica

@solnic

it does, there are cases where you really do want to validate the structure, not just values

ie in my current project at work it is the requirement

Andy Holland

@AMHOL

Fair enough, makes sense to do that then

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

Where communities thrive

People

Repo info

Activity