dry-rb/chat

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

Piotr Solnica

@solnic

otoh it should be private

we want access to successes and failures

@timriley btw how does successes sound?

Tim Riley

@timriley

Sounds fine to me.

Piotr Solnica

@solnic

ok :)

Tim Riley

@timriley

It’s clear.

Piotr Solnica

@solnic

I’m about to break things /cc @timriley @kwando

timriley @timriley stops upgrading ;)

Piotr Solnica

@solnic

schema.messages(input) => schema.(input).messages

YOU CAN UPGRADE USING sed OK?!

Tim Riley

@timriley

oh, this is a nice upgrade!

Piotr Solnica

@solnic

almost there with refactor

Piotr Solnica

@solnic

so, for fun, I stubbed I18n in AM::V and ran the benchmark

Calculating -------------------------------------
ActiveModel::Validations
                       628.000  i/100ms
      dry-validation     1.948k i/100ms
-------------------------------------------------
ActiveModel::Validations
                          5.933k (± 1.5%) i/s -     30.144k
      dry-validation     20.386k (± 7.6%) i/s -    103.244k

Comparison:
      dry-validation:    20385.8 i/s
ActiveModel::Validations:     5932.6 i/s - 3.44x slower

this is AM::V WITHOUT COERCION AND WITHOUT I18n

BUT

dry-v is WITH coercion and WITH message compilation

and it’s ~3.5x faster :joy:

Tim Riley

@timriley

:tada:

Piotr Solnica

@solnic

@timriley @AMHOL dryrb/dry-validation#23

as discussed with Andy we will be able to configure error compiler per schema, so ie you can set up a schema with I18n-compatible compiler and your localized errors will be used

Tim Riley

@timriley

This makes a lot of sense.

Piotr Solnica

@solnic

there’s a bit more to it, but it’s a bigger subject: validation hints :)

in the near future we’re gonna have a way to generate user-friendly representation of validation rules, even for those that were not used in the validation process

Tim Riley

@timriley

Yeah, that sounds handy!

Piotr Solnica

@solnic

so ie when you have age.int? & age.gt?(18) and it turned out to be an empty string we still need to provide meaningful info to the user

since we have access to all the rules we can simply use the same technique to produce validation hints (as I call it)

we can automatically drop type expectations, since it’s too low level IMO, and just do things like gt?(18) => “age must be greater than 18”

Tim Riley

@timriley

Wonderful :)

Piotr Solnica

@solnic

we can actually be pretty precise here, and take into consideration whether or not a value was present

so ie pattern match on input and have things like “oops, you forgot to fill in age"

or “hey, sorry but your age must be greater than 18, you gotta wait 2 years” :D

hints will be useful when there are many rules though, so we want to be smart and display only what’s relevant to the user

ie displaying ‘age can’t be blank’ and ‘age must be greater than 18’ is redundant from the user pov

I mean the former msg is redundant

since the latter implies the former

Tim Riley

@timriley

Yeah. Many of those decisions you could make programatically, but in some schemas, it may be hard to guess correctly.

Piotr Solnica

@solnic

common stuff should be simple

filled? vs more specific predicates is a good example, I think

so ie if filled? failed but we have more rules, then we’re gonna be interested in error msgs for the other rules

or I should say, validation hints, those won’t be errors since filled? failure is the only error when a value is blank, the rest is just providing hints for the value and its constraints

actually, it’s probably a good idea to always ignore filled? failure when there are other rules, can’t think of any reason why you would want to display age cannot be blank + more info about other rules

Tim Riley

@timriley

Yeah.

Filip Bartuzi

@Bartuz

hello

Piotr Solnica

@solnic

hey ho

Filip Bartuzi

@Bartuz

have you already started working on i18n support? Is there dedicated branch for that?

Piotr Solnica

@solnic

not yet

Filip Bartuzi

@Bartuz

Ok, great. I would like to contribute

Piotr Solnica

@solnic

cool! I gotta clean up current error compiler and come up with some common interface so that buiding new compilers will be simple

we talked with @AMHOL that maybe it’s gonna be possible to only have Messages and its sub-classes for specific backends

Where communities thrive

People

Repo info

Activity