dry-rb/chat

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

Piotr Solnica

@solnic

sounded so serious when I wrote it :D

Hannes Nevalainen

@kwando

oh? you're spoiling us <3

Piotr Solnica

@solnic

dry-data is extendible, so is dry-validation

Hannes Nevalainen

@kwando

I don't really like the globalness of Dry::Data right now

Piotr Solnica

@solnic

yeah, I will probably add a way of setting your own container

I also thought about having a way to define types under constants, so it feels more natural to define things like attribute :foo, MyTypes::Something::Foo

but I dunno, we’ll see

Hannes Nevalainen

@kwando

cool =)

feels like you have a plan for everything =P

Piotr Solnica

@solnic

I certainly don’t, but I’ve thought about a ton things, I gotta say :)

Piotr Solnica

@solnic

https://github.com/dryrb/dry-validation/blob/rule-groups/spec/integration/rule_groups_spec.rb

@kwando ^^ :)

@AMHOL ^^

lemme know if you have some dsl ideas for that

we definitely need a way to explicitly name a group, which will be needed for messages, although this could default to concatenation of rule names within a group

eventually this will be nestable too, ie a group depending on another group etc

it should also be possible to create a group from rules that are applied to values from different levels of nesting

Piotr Solnica

@solnic

if you think that’s crazy, I can assure you this kind of requirements exist :joy: I’ve got a ton of this stuff in my current client project

Andy Holland

@AMHOL

@solnic I don't get what group is doing differently? Is it that it's calling an existing predicate with the values from two keys?

Group seems a bit of a strange name for that

Hannes Nevalainen

@kwando

I not sure about the name, but the functionality :thumbsup:

Piotr Solnica

@solnic

@AMHOL it groups rules so...

I mean I’m open to other names of course

the rule is called Rule::Group and is identified as :group because it is a…group :)

Andy Holland

@AMHOL

Just looks like an eql predicate in the spec

Piotr Solnica

@solnic

it accepts multiple args as input, so it’s different

we could just use rule(eql?: [:pass, :confirm]) maybe

Tim Riley

@timriley

That one reads better to me.

Piotr Solnica

@solnic

cool, I think I like it more

Tim Riley

@timriley

If I saw the word “group” used in a validation schema, I’d expect it to allow a disparate set of predicates (on multiple keys, even) that would all need to pass together, or something.

Andy Holland

@AMHOL

Yeah, rule works nicely IMO, much less confusing

Piotr Solnica

@solnic

Class.new(Dry::Validation::Schema) do
  confirmation(:password)
end

cannot be more concise than this :joy:

Andy Holland

@AMHOL

Piotr Solnica

@solnic

@AMHOL btw, uniqueness validation backed by a db should be very simple to achieve now

Andy Holland

@AMHOL

Nice, guess it will still need a global connection?

Piotr Solnica

@solnic

basically include App::Import(‘persistence.relations.users’) and def unique?(key, value); users.unique?(key => value);end

injected from container

Andy Holland

@AMHOL

Ahh OK, so we need to make a new predicate for each unique constraint, makes sense :+1:

Piotr Solnica

@solnic

@AMHOL well, it’s just a key rule

Andy Holland

@AMHOL

Could probably do some hocus pocus to make a generic one, but would probably be a bad idea

Piotr Solnica

@solnic

key(:email, &:unique?) will partially apply :email to the predicate

then value will be passed

so it’s gonna Just Work™

@AMHOL I will do the hocus pocus in rom-model for that

Andy Holland

@AMHOL

Yeah, I was more meaning say if you wanted a constraint on users#email and then another on credential#token for example

Piotr Solnica

@solnic

but a generic orm-agnostic/db-lib-agnostic predicate would be insane IMO

Andy Holland

@AMHOL

Ahh, cool

Yep, v.bad idea

Nice work BTW, looking awesome

Where communities thrive

People

Repo info

Activity