These are chat archives for dry-rb/chat

2nd
Feb 2016
Hannes Nevalainen
@kwando
Feb 02 2016 10:14
dry-* = :heart: good job all of you!
Piotr Solnica
@solnic
Feb 02 2016 11:01
@kwando <3 dry-revolution is coming :joy:
Pascal Betz
@pascalbetz
Feb 02 2016 11:31

@solnic

is dry-revolution already published? and what does it do?;-)

Piotr Solnica
@solnic
Feb 02 2016 12:41
@pascalbetz it detects ActiveSupport monkey patches and undefines them ;)
Pascal Betz
@pascalbetz
Feb 02 2016 12:55
stay away from the dark side you must, young coder.
Seba Gamboa
@sagmor
Feb 02 2016 14:05
Just in case:
RSpec.describe 'Project' do
  it 'is free of active support' do
    expect(Bundler.default_lockfile.read.match(/(active|action)/)).to be_nil
  end
end
Piotr Solnica
@solnic
Feb 02 2016 14:08
:joy:
Oskar Szrajer
@gotar
Feb 02 2016 14:52
:D
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 15:31
:joy_cat:
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:34
How do I add a custom coercion to dry-validation?
      module Types
        ZipCode = String.constrained(format: /\d{5}-\d{3}/)
      end
if I had that type, how can I call: value.zip_code? or soemthing like that.
Piotr Solnica
@solnic
Feb 02 2016 16:34
@mrbongiolo this is not a coercion, it’s a constraint
I’ll add support for passing types as predicates in 0.8.0
or 0.7.1
ie key(:zip_code, Types::ZipCode)
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:36
okay
but is there a way to use custom coercions right now?
Piotr Solnica
@solnic
Feb 02 2016 16:38
there’s no public API for custom coercions yet
what kind of coercion are you talking about?
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:39
well as you said, I just got it a bit wrong, zipcode can be used as a constraint
Piotr Solnica
@solnic
Feb 02 2016 16:39
ok, so what’s your expected behavior?
to get an error instead of validation result?
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:40
actually I would expect a validation, since I need to send that back to the api user...
not sure how the coercion errors are being shown now...
what would happend if I send: zipcode: '1234-456'?
Piotr Solnica
@solnic
Feb 02 2016 16:42
my intention is to infer validation logic from type defs
so it’d be a validation result, not an error
just checking with you if we’re on the same page here
looks like we are
there is no “coercion error” in dry-v
it tries to coerce and provides an validation error if coercion returned original input, that’s how form.* types work in dry-data
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:44
zipcode could even be a Dry::Data::Value actualy or something like this.
Piotr Solnica
@solnic
Feb 02 2016 16:45
that would be weird
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:46
but '12345-123' == '12345-123'
Piotr Solnica
@solnic
Feb 02 2016 16:46
values have one or more attributes
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:46
uhm
Piotr Solnica
@solnic
Feb 02 2016 16:46
it’s a value object
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:46
then it would be weird :)
Piotr Solnica
@solnic
Feb 02 2016 16:46
maybe I should rename to ValueObject
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:47
and in the case of location with lat and lng, those could be used in validations?
Piotr Solnica
@solnic
Feb 02 2016 16:47
we could infer validations for value objects
ie key(:location, Types::Location)
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:47
Yup, something like that
Piotr Solnica
@solnic
Feb 02 2016 16:48
where Location has two attrs with constraints
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:48
the incoming hash should be: location: { lat: 1.12, lng: 1.23} then?
Piotr Solnica
@solnic
Feb 02 2016 16:48
yes
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:48
that would be nice, right now I can manually validate on lat and lng
Piotr Solnica
@solnic
Feb 02 2016 16:49
when the input structure matches your types and you re-use these types across your app then it would be pretty sweet, I have to say
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:49
yeah, I have to use locations in some places of the app
Piotr Solnica
@solnic
Feb 02 2016 16:50
btw I finished first round of error-compiler refactor, all specs are passing except some weirdness on rbx where args.hash returns the same value for two different arrays O_o
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:50
bah, having to mess with dry-data into rails is quite a pain...
Piotr Solnica
@solnic
Feb 02 2016 16:51
add it to initilizer
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:51
BTW, should I register custom Types in the initializer also?
Piotr Solnica
@solnic
Feb 02 2016 16:51
and install dry-data-rails gem
@mrbongiolo no need for that, define them wherever you want
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:52
Ah ok
Just gotta do it after Dry::Data.finalize right?
Piotr Solnica
@solnic
Feb 02 2016 16:53
@mrbongiolo yes, finalize defines built-in types in the configured namespace
Vladimir Kochnev
@marshall-lee
Feb 02 2016 16:53
hello
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:54
Hi @marshall-lee !!
Piotr Solnica
@solnic
Feb 02 2016 16:54
so, I figured out how to make hints smart, that’s good news, bad news is that it’s gonna be a bigger chunk of work, so I’ll do that in 0.8.0
Vladimir Kochnev
@marshall-lee
Feb 02 2016 16:55
dryrb/dry-pipeline#2 what do you think?
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:56
@solnic dv Schema::Form implies value.str?
Piotr Solnica
@solnic
Feb 02 2016 16:56
I basically need to come up with a way of building up a map of predicates that can be applied for each node, and then diff that with a result from applying a schema and see which predicates were applied successfuly, having that it will be only a matter of skipping those when generating hints.
@mrbongiolo yes it does
hey @marshall-lee
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 16:59
@solnic so if you had 3 rules for a key and it errored on the 2nd, you would still show the 2nd and 3rd errors?
Piotr Solnica
@solnic
Feb 02 2016 17:03
@mrbongiolo yes
that’s the whole idea behind hints, we don’t apply all predicates because it follows predicate logic, but often you need to provide info about the constraints/requirements for particular values
it’s tricky, but doable
I mean, it already works, but it’s not optimized yet
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 17:09
if we had key(:foo) { |foo| foo.str? & foo.filled? & foo.size?(3) } with input: foo: '', then the error would be: must be filled, must be size 3?
this validation is a bit stupid, but not sure if size already implies filled
Piotr Solnica
@solnic
Feb 02 2016 17:25
@mrbongiolo yeah it’s gonna provide two msgs, one for filled? and one for size?
at the moment, at least, and it’s exactly something I want to improve in 0.8.0
Piotr Solnica
@solnic
Feb 02 2016 17:54
so, given that error hash for arrays includes now a mapping { el_index => msgs }, do we still need original inputs in the result hash? ie:
payments: {
  1 => {
    method: [['+method+ key is missing in the hash'], nil]
  }
}
@timriley ^^
we’re generating a ton of additional arrays because of that and it makes generating hints more complicated, so I’d like to get rid of that, notice that in the error objects you do have all the info, in case you wanted to do something less standard with error messages
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 18:58
could you get the original input in any other way?
Piotr Solnica
@solnic
Feb 02 2016 18:59
well, you have the input structure available
you also have access to very detailed result object with error objects that have all rule results
#messages interface is meant to be used for display purposes, as in - whenever you want to return validation error messages in human-friendly form to the client
for some advanced processing that, let’s say, some library integration may require (like reform), other APIs could be used
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 19:05
I like messages being simples for messages
since, most of the cases just need straightforward messages
Piotr Solnica
@solnic
Feb 02 2016 19:06
yep
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 19:06
I wouldn't have a problem to use the result object or some other API to implement a different errors object, if it would be needed
BTW, messages show field + message or just the message?
AM:V has that full_messages that add the field directly to the message if needed
Piotr Solnica
@solnic
Feb 02 2016 19:08
default messages have %{name} tokens embedded so each message has ‘field’ name too
I really dislike this full_messages API
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 19:09
yeah, I'm not saying to use it. But just error messages without the field is good when you show the error next to the field
it isn't that bad, but a bit strange to have "name can't be blank" just under the name field itself..
Piotr Solnica
@solnic
Feb 02 2016 19:10
you can just provide custom messages and remove %{name} from them
no need for a special API, I think
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 19:13
uhm
Piotr Solnica
@solnic
Feb 02 2016 19:13
we could add an option for that, I’ll wait for feedback
Ralf Schmitz Bongiolo
@mrbongiolo
Feb 02 2016 19:13
yeah, better mess with it later on when more people are onboard
to see real usage cases
you could have one schema with fieldless custom messages if needed
the configuration is per schema right?
Piotr Solnica
@solnic
Feb 02 2016 19:51
@mrbongiolo it is, yes
you could configure a schema to use a completely different set of error messages
you can also define an abstract app schema with a specific configuration and inherit other schemas from it