Next-gen ruby libs! » github.com/dry-rb » website: https://dry-rb.org » forum: https://discourse.dry-rb.org
@selectport pls report an issue about it and I can add it in 0.8.1 :)
@solnic should we delete this example? https://github.com/dry-rb/dry-validation/blob/master/examples/rule_ast.rb a) ast is wrong, b) both of the classes referenced have been moved to dry-logic c) even when you fix a&b it still doesn't work...
@fran-worley btw I partially rewrote error compiler :laughing:
:) nice! dry-rb/dry-validation#185 can probably go then. Still think we are going to have to rename the tokens at some point though...
@solnic I opened (dry-rb/dry-validation#204) with failing spec added …let me know if you need more. thank you.
@fran-worley yeah I will revisit this PR once I’m done
@fran-worley we actually should be able to reduce dry-logic result ast a bit…specifically
:input nodes could be removed probably
that’s for 0.9.0 though, I’m refactoring error compiler mostly because I couldn’t easily fix one bug
I wasn't sure how you tell the difference between the 'input' parameter and others particularly when allowing custom predicates. Also I quite like being able to have the complete predicate, particularly when using it for my non-validation based use case.
If we didn't need the input arg then changing the ast would have been 100% simpler !!
I’m 90% sure we won’t need it at the end of the day
but that’s too much to change at once, so I’m gonna do it step by step in two releases
I’m introducing a couple of new abstractions in 0.8.1 as part of this refactor, it won’t be exposed as public yet but it will be there :) so ie we will have messages set which stores message objects, and we have info about which are errors and which are hints
so in 0.9.0 we could have a result object that can give you errors and hints separately if you want
clever. That should fix a load of the pending specs. The second point would be awesome. I can then actively use hints without any effort !
it’s a classic example of primitive obsession biting you in an OO lang
Hey :) once again (sorry to bother but dont know if it is doable witg dry-val)
@solnic is there a way to somehow validate hash keys? I would like to describe something like htis:
{ 1 => rand, 2 => rand } # etcand create sme rules with dry-validations that will ensure that my keys are integer based and that inside there are float numbers as well
@solnic No worries if not and I think I know the answer but is there any update on rule groups or such like? (see your comment here)
https://github.com/apotonick/reform/pull/347#issuecomment-204923689
https://github.com/apotonick/reform/pull/347#issuecomment-204923689
@fran-worley I won’t have time for this in the near future, but would be nice to get it done prior 1.0
I don’t have any API ideas yet
@solnic Famous last words but I'm happy to try and push this forward for 0.9
I like using groups to help to order my validations and ignore DB hitting checks like uniqueness if my basic ones like filled fail. I'm therefore wondering whether we could expand on the
I like using groups to help to order my validations and ignore DB hitting checks like uniqueness if my basic ones like filled fail. I'm therefore wondering whether we could expand on the
schema do .. end api to achieve this. # If you could name your schemas
schema(:simples) do
# ...
end
schema(:scary_complex) do
# ...
end
# we could enable rules like:
schema(:simples).success?.then schema(:scary_complex)
you can achieve the same thing with high lvl rules
The thing I wasn't sure of was if you could check more than one thing easily. Take this example:
validation :default do
required(:email).filled
required(:current_password).filled
end
validation :authenticate_current_password, if: :default do
configure do
def account_authenticated?(value)
form.model.authenticate(value)
end
end
required(:current_password, &:account_authenticated?)
end
In that example I only validate the second schema if the first passes. Would you be able to support that somehow?
which was my idea from the beginning btw
so ie
schema1.and(schema2) would work
schema1 | schema2
etc
I think we should be careful with adding more stuff to the DSL
schema is already quite complex
we now have a 3-step process which is quite a lot
I completely agree. surely if done properly it should impact people just needing the basic form:
each do
schema do
required(:prefix).filled
required(:value).filled
end
end
huh dry-v crossed 15k downloads, that’s quite a lot given that rom-rb has only 2 x more and it was released in 2013 :laughing:
yeah and probably because more people would like to use a new validation lib as opposed to ditching their favorite orms ;)
@solnic it's a pretty easy sell, and as it works happily with rails, along side ActiveModel::Validations people can try it out, gradually migrate etc. ROM probably takes a little more guts to dive into ...
Should I change my current rules
required(:something).filled(:str?) to the new required(:something, :str).filled?
@mrbongiolo these two are not equivalent
type specs are only used for coercion
you still need predicates to ensure that coercion succeeded
@fran-worley lemme know if you’d like to experiment with dry-logic result ast reduction (removing
:input nodes)…I’m gonna take a break from dry-rb after 0.8.1 release of dry-v to focus on rom-rb so I suspect I won’t be doing much dry-rb work in July
@solnic Ok, thanks for the explanation. So in the earlier versions the predicate
:str? was doing type checking and coercion?
@mrbongiolo coercion was inferred from type-checking predicates
I mean it still works like that
but we’re gonna remove it in 1.0.0
we just need to figure out a way to make it smooth in common cases with zero duplication in dsl
so ie infer predicates from type specs for common cases
I also want to experiment with a different approach where you use type-check schema separately from domain schema
the
schemas as rules idea would help here
this is 1.0.0 material :)
I start to think we should be able to hit 1.0.0 for validation and types later this year, becoming more confident about this (slowly)
@solnic I know exactly how to remove it and it will simplify things (we won't need to curry the rule for the result). I just worry that pulling it out leaves a hole in dry-logic. I get that dry-validation doesn't need it because it does input it's own way but what about other uses of dry-logic.
and because we curry, we don’t need to add
:input nodes anymore
sorry take this dry-validation ast:
[
[:error, [:name, [:input, [:name, [:result, [nil, [:val, p(:key?, :name)]]]]]]],
[:error, [:gender, [:input, [:gender, [:result, [nil, [:val, p(:key?, :gender)]]]]]]],
[:error, [:age, [:input, [:age, [:result, [18, [:val, p(:gt?, 18)]]]]]]],
[:error, [:email, [:input, [:email, [:result, ["", [:val, p(:filled?)]]]]]]],
[:error, [:address, [:input, [:address, [:result, ["", [:val, p(:filled?)]]]]]]]
][:error, [:name, [:result, [nil, [:val, p(:key?, :name)]]]]]
:result has info about the input for a rule, and its predicate has info about actual args
Ahhh that makes more sense. You had me panicking that you wanted rid of the input in the predicate ast.
[:predicate, [:key?, [[:name, nil], [:input, nil]]
Indeed I was thinking that the extra input could probably go when I made the original change. I'll take a look :)
Or do I need to also remove the key ? @solnic
yeah rule name must go, first element in a node defines its type
@solnic What about each rules? If you take the name away we don't seem to keep it anywhere (or doesn't that matter)?
[:input, [
:nums, [
:result, [
[1, '3', 3],
[:each, [
[:el, [0, [:result, [1, [:val, [:predicate, [:str?, [[:input, 1]]]]]]]]],
[:el, [2, [:result, [3, [:val, [:predicate, [:str?, [[:input, 3]]]]]]]]]
]]
]
]
]]
# would become:
[ :result, [
[1, '3', 3],
[:each, [
[:el, [0, [:result, [1, [:val, [:predicate, [:str?, [[:input, 1]]]]]]]]],
[:el, [2, [:result, [3, [:val, [:predicate, [:str?, [[:input, 3]]]]]]]]]
]]
]][:result, [:nums, […]]]
so first arg is name, then the input value, then the elements array
Yeah that's better:
[ :result, [[:nums, [1, '3', 3]],
[:each, [
[:el, [0, [:result, [1, [:val, [:predicate, [:str?, [[:input, 1]]]]]]]]],
[:el, [2, [:result, [3, [:val, [:predicate, [:str?, [[:input, 3]]]]]]]]]
]]
]]
@solnic if you've got time can you check the updated specs? dry-rb/dry-logic@7dd5053
after updating
dry-transaction to 0.7 i get this in my code undefined method `Right'
is there some upgrade steps that were not mentioned
@joshuaswilcox I’m guessing you need to
include Dry::Monads::Either::Mixin
or just do
Dry::Monads.Right(…) explicitly
hm, ok, i'll give that a try, i thought I saw it being included by the the transaction.rb already in the gem though
@joshuaswilcox we changed kleisli gem with dry-monads, the main difference is that we don't monkey patch Kernel so now you have to include Either::Mixin manually to add Right/Left methods
Ah, ok, yeah I saw it was replaced, makes sense about the monkey patching as well, thanks
uhm, I enabled caching for I18n thinking that maybe it’ll speed up ActiveModel::Validations and it basically made it 2 x slower O_o
and when I disabled caching in dry-v, it was ~2.5x slower
Is there a way in dry-types to automatically build fake objects for testing easily?
Say I have a User object with an array of addresses and I don't want to write factory methods
I just want to do User.build and it'll make a User object with all the fields populated