hey I gotta run
I’ll describe my rodakase vision and put it in a readme soon
cheers
:wave:
Just wanted some advice on https://gist.github.com/AMHOL/dcc99af2c2d5034453d9
The gist vs the comment
I'm leaning towards the gist myself, that would allow the processor to be switched out for nested validations or anything else someone wants to do
Then I can put the extractor/validation container config on the processor
WDYT?
v = Dry::Validator.new(
name: {
presence: true
},
test: {
embedded: {
tester: {
presence: true
}
}
}
)
v.call(name: '', test: { tester: '' })
# => {:name=>[{:code=>"presence", :options=>true}], :test=>[{:tester=>[{:code=>"presence", :options=>true}]}]}
v.call(name: 'Joe', test: { tester: 't' })
# => {}
v = Dry::Validator.new(
users: {
each: {
name: {
presence: true
}
}
}
)
v.call(users: [{ name: 'Joe' }, { name: '' }])
# => {:users=>[{}, {:name=>[{:code=>"presence", :options=>true}]}]}
v.call(users: [{ name: 'Joe' }])
# => {}
because Dry has been misunderstood by many rubyists and not everybody realized what it really means
:sparkles:
AR DRY
Was wondering whether this was going to turn into a framework last night lol
I think that developing these small libraries with small concerns makes for better code
it’s called dependency hell :)
it’s the reason why I don’t like to start with small libs and prefer extractions
and I am very very careful about deciding when it’s good to extract
extracting unstable code will always mean much more work
we’ve been there with DM2 that’s how I’ve learned it, the hard way™
I’m talking about things like building a biggerish thing like ROM via bottom-up approach, that part didn’t work at all for DM2
hey so