Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Pablo Herrero
@pabloh
@flash-gordon , OTH, is there a reason you make it optional?
for instance, people usually don't understand or don't want to use monads?
or just to have one fewer dependency?
Nikita Shilnikov
@flash-gordon
@pabloh because we want a user to control the dependencies
there are some libs already which depends on dry-v and we care :)
Pablo Herrero
@pabloh
yup, like types and struct, i saw that
but maybe the use of monads should be encouraged here, since we are following a FP style
Nikita Shilnikov
@flash-gordon
heh, I meant like hanami and trailblazer ;)
Pablo Herrero
@pabloh
oh, you meant transitive dependencies, sorry...
Well, good to know I can use them that easily if I want
Nikita Shilnikov
@flash-gordon
@pabloh we don't push monads too hard to not be known as weird geekers in ruby community ... more than we are
just kidding :)
Pablo Herrero
@pabloh
hahahaha
now that you mention it I'm a bit surprised how often I find people using dy-rb o rom-rb, at least indirectly, these days...
mostly for form objects and validations, but it's a start
Nikita Shilnikov
@flash-gordon
yes, dry-v is the most advanced gem from dry-*s atm
Calinoiu Alexandru Nicolae
@alexandru-calinoiu
Hi, at a 24 hackaton trying to spin a up a quick and fast rest api, is there a how-to get started for dry-web?
Calinoiu Alexandru Nicolae
@alexandru-calinoiu
Usintg https://github.com/dry-rb/dry-web-roda for now, hope it does the trick.
Oskar Szrajer
@gotar
@alexandru-calinoiu yeah, but it's a lot of new stuff and concepts if you never use dry-* before
if you have any problems or questions just ask
@alexandru-calinoiu Plus this may helps: https://github.com/dry-rb/dry-web-blog much simpler exmaple
for simle API
oh ok it's not api exmaple any more ;] but maybe will still help
John Backus
@backus
Nice ^ Sounds like a big improvement
Don Morrison
@elskwid
Agreed. I like the divide.
Piotr Solnica
@solnic
I should mention that “schema” will be an abstract concept in dry-validation
so any object implementing required interface will work
Tim Riley
@timriley
Oh good, I was going to ask about whether a validation class would require a local schema definition, or whether you could pass one in.
In fact, in a system where your schemas are on the edge, would you need to pass it to the validation object at all, given you know you've already passed your data through it?
Piotr Solnica
@solnic
@timriley yes because a schema defines the input structure so we can easily extract specific values for other rules
a validator needs to know what it’s dealing with
so ie you’d be able to define an HTTP schema at the boundary, and use it in a validator by connecting the two
but you won’t have to define it in the validator itself
I would like to have a way of defining schemas for every http endpoint somehow
we can also do this the other way around, define plain schemas in validators, and infer http schemas from them for http end-points
Tim Riley
@timriley
Right
I like the of comprehensive endpoint scheme definition
The idea of*
Piotr Solnica
@solnic
r.get(“search”) do |r|
  r.schema do
    optional(:q).filled(:str?)
  end

  r.view(‘users.index’, params: { q: s[:q] })
end
maybe this is doable for roda ^
this can define schemas on the fly (and cache them) and then expose s (or something) to access processed params
it can register these schemas in the container and then you could just do:
class UserSearchValidator < Dry::Validation::Validator
  include Import(schema: “schemas.users.search”)

  rule(:q) { |q| … }
end
not the best example but you should see the idea regardless
the beauty of this approach is that http stuff doesn’t leak into domain land
@timriley ^^
we can easily add a shortcut in dry-web ie class UserSearchValidator < Dry::Validation[“schemas.users.search”]
Piotr Solnica
@solnic
I’m hoping that if we make this really easy, folks will start validating http params for all end-points, this should make apps more secure and crash less
I also love the fact it can self-document end-points
we can easily add additional APIs for annotating schemas with docs, and generate API docs from that, all kinds of nice things are possible