dry-rb/chat

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

Mikhail Slyusarev

@mikhailvs

either way. it seems like a very cool collection of libraries

John Backus

@backus

If you have good tests I think you should be safe although I can't vouch for containers and transactions

just lock yourself to a strict version

Mikhail Slyusarev

@mikhailvs

yeah... for sure

Piotr Solnica

@solnic

@mikhailvs what’s your concern?

Mikhail Slyusarev

@mikhailvs

Honestly, I've only very recently stumbled upon dry-rb, and it's hard to gauge how widely it's being used. I suppose it's not a real concern though, more like curiousity.

Piotr Solnica

@solnic

@mikhailvs it’s used on production by many people

it is unstable though, so APIs may change from time to time until we hit 1.0.0

Mikhail Slyusarev

@mikhailvs

Is there a way to set a message for a custom dry-validation predicate without loading a yaml file?

Piotr Solnica

@solnic

not yet

I mean…it is possible to merge in your own messages

https://github.com/dry-rb/dry-validation/blob/master/spec/integration/custom_predicates_spec.rb#L197-L210

Mikhail Slyusarev

@mikhailvs

is that not recommended/

what you linked to actually seems like a pretty sane way of doing that

Piotr Solnica

@solnic

well, I don’t like it but it doesn’t mean it’s not recommended. personally I dislike having core objects of my system cluttered with UI-related configurations

Mikhail Slyusarev

@mikhailvs

I can see that. I'd still feel like there's UI stuff polluting backend code with a yaml conf file though... especially with api driven apps.

Piotr Solnica

@solnic

how come? that’s a nice separation, just like you separate html templates from objects that provide data for rendering, it’s somewhat similar here

Mikhail Slyusarev

@mikhailvs

I mean it's stuff that shows up on the frontend, being defined in files of the backend project.

Piotr Solnica

@solnic

you could render them on the client side and have message templates defined there

Mikhail Slyusarev

@mikhailvs

I'm not saying I have a different/better approach though. But it seems like the kind of error something is, is coupled with the text description of it, and since the error is generated on the backend, it's fine for other components of it to be defined there as well.

yeah, that's what I'd do if I felt super strongly about it

Piotr Solnica

@solnic

it’s actually not coupled, we translate generic result object into whatever we want, but since generating string messages is what most people need, it’s been baked into the library

I just made it work with plain YAML because some times you may want to skip i18n as a dependency

Mikhail Slyusarev

@mikhailvs

Well when you create a custom predicate for a schema it seems like there's at least a logical coupling of its definition and the error message it could generate

Piotr Solnica

@solnic

you can still apply that predicate w/o generating a message

messages are generated only when you ask for them

Mikhail Slyusarev

@mikhailvs

as in, when you call .messages?

Piotr Solnica

@solnic

right, or in 0.10.0 errors

Mikhail Slyusarev

@mikhailvs

that makes sense

Piotr Solnica

@solnic

irb(main):004:0> Dry::Validation.Schema { required(:num).value(:int?) }.(num: 'not num').results[0].ast
=> [:key, [:num, [:predicate, [:int?, [[:input, “not num”]]]]]]

^^ here’s a result AST, gives you all info you need to generate whatever you want from it

Mikhail Slyusarev

@mikhailvs

well in my case I do need the message and I'm getting Dry::Validation::MissingMessageError if there isn't one. I think since my schema is in its own file/module it's fine to just put the messages for the custom stuff into the configure block

Piotr Solnica

@solnic

yep, as I said, if you like it, just do it :)

Mikhail Slyusarev

@mikhailvs

fair enough. in any case, separating the schema definition (sans predicate implementation) into its own file makes it sort of like a configuration file anyway

i just dont want to feel bad about what i'm doing... :P

Piotr Solnica

@solnic

it’s gonna be easy to move them to a yaml config when you feel like they make schema defs messy :)

Mikhail Slyusarev

@mikhailvs

i guess my problem is that i'd have to load the file each time i define a schema...

would doing Dry::Validation::Messages.default.merge!(...) one time on app init work?

nvm, doesnt look like theres a merge! implemented

Piotr Solnica

@solnic

@flash-gordon https://travis-ci.org/dry-rb/dry-validation/jobs/161531234 is this expected? :)

Alexander Gräfe

@rickenharp

Is there a way to debug rules in dry-validations? I'm trying to find out what values are actually passed to the rule, but using puts inside the rule leads to +puts+ is not a valid predicate name

Mikhail Slyusarev

@mikhailvs

where in the definition are you using puts?

Alexander Gräfe

@rickenharp

rule(valid_blockname: [:ist_blockname, :name]) do |ist_blockname, name|
  puts ist_blockname
end

Mikhail Slyusarev

@mikhailvs

you should try Kernel.puts

or ::Kernel.puts

Alexander Gräfe

@rickenharp

That works perfectly, thanks!

Alexander Gräfe

@rickenharp

Is it possible to model this in dry-v? first_name and last_name must be filled. Unless blockname is true, in which case first_name must not be filled.

Nikita Shilnikov

@flash-gordon

@solnic I bet this is not :) looking at it

I think before(:all) { load_extension } is a bad approach, should be reworked in the same way as in dry-t

Luca Guidi

@jodosha

@solnic @flash-gordon probably new dry-logic broke rom-sql build (master) See https://gist.github.com/jodosha/55651fe8033477cba882c2af17ee8c9a.

@solnic I confirm that picking dry-types (master) in Gemfile fixes the problem. :)

Where communities thrive

People

Repo info

Activity