Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Piotr Solnica
@solnic
@matheussilvasantos required(:sample).maybe(included_in?: [1, 2, 3])
Matheus Silva Santos de Oliveira
@matheussilvasantos
@solnic thank you!!
Igor Alexandrov
@igor-alexandrov
@matheussilvasantos if you have optional key (it may be missed in input) then you should use optional instead of required
optional(:sample).maybe(included_in?: [1, 2, 3])
Igor Alexandrov
@igor-alexandrov
irb(main):013:0> VALUE = 1
=> 1
irb(main):014:0> Dry::Monads::Success(Dry::Monads::Success(VALUE))
=> Success(Success(1))
I always thought that it should be just Success(1)
Igor Alexandrov
@igor-alexandrov
Don't know maybe #flatten or #compact should be added for such cases
Nikita Shilnikov
@flash-gordon
you usually use fmap/bind depending on the case, there's no flatten/join because it's normally not required
flattening by default will ruin the semantics
it won't "type check"
Igor Alexandrov
@igor-alexandrov
Ok, got it
Thanks!
Igor Alexandrov
@igor-alexandrov
The question above was because we tried to combine Try and Result monads, but we found a solution:
irb(main):003:0> Try { Failure(5) }.to_result.bind(&:itself)
=> Failure(5)
irb(main):004:0> Try { raise RuntimeError.new }.to_result.bind(&:itself)
=> Failure(#<RuntimeError: RuntimeError>)
irb(main):005:0> Try { Success(1) }.to_result.bind(&:itself)
=> Success(1)
Matheus Silva Santos de Oliveira
@matheussilvasantos
@igor-alexandrov yes, I'm using optional :smile:
hasimisikli
@hasimisikli
@solnic hello ,firstly thanks of uploaded. can I ask a question?
can you explain this project please?
Igor Alexandrov
@igor-alexandrov
@hasimisikli you mean to explain dry-rb?
hasimisikli
@hasimisikli
Yes.
Grant Shangreaux
@gcentauri
"dry-rb is a collection of next-generation Ruby libraries, each intended to encapsulate a common task"
https://dry-rb.org/news/2016/03/16/announcing-dry-rb/
https://dry-rb.org/news/2016/08/15/introducing-dry-system/
@hasimisikli that might get you started
Herwin
@herwinw
Does dry-validation have something like input input.strict of dry-struct? I can't find any indication of it in the documentation
Igor S. Morozov
@Morozzzko
What are you trying to achieve?
Herwin
@herwinw
Working with a legacy app where a lot of logic is based on a nested hash. I'm convinced some keys have become obsolete and some keys contain typos, so I'm trying to work backwards to a schema where every entry of the hash adheres to, that gives a starting point to see what keys exactly exist. So I want the validation to error if extra keys are given.
I could also use dry-struct for it, but I'm not interested in the resulting struct (yet), and dry-validation gives more readable errors
Matheus Silva Santos de Oliveira
@matheussilvasantos
Is there a way to get only valid attributes from to_h method of Dry::Validation::Result?
Igor Alexandrov
@igor-alexandrov
to_h just returns an output which includes everything. But you can always compare output with errors and exclude keys that you don't need.
Alex Park
@alexspark
Hi all, new to all thing dry here, i really like the APIs. Can someone guide me on how to coerce boolean strings but protect against weird strings like 'please'. attribute :active, Types::Params::Bool.constrained(included_in: [true, false]) throws errors in the gem
Alex Park
@alexspark
One work around I've thought of is to constrain the attribute as a string to only be one of 'true' or 'false', then try to coerce to boolean
Igor Alexandrov
@igor-alexandrov
you don't need constrained with Types::Params::Bool
because Types::Params::Bool already converts everything to true or false
Alex Park
@alexspark
but Types::Params::Bool['please'] returns 'please', and I don't want to assume sensible inputs.
which abstraction should i use to ensure only 'true' and 'false strings as input
Igor Alexandrov
@igor-alexandrov
I see...
From my point of view it is a bug...
please start an Issue
I will try to take a look
Alex Park
@alexspark
:+1: dry-rb/dry-types#276
Oskar Szrajer
@gotar
Hi, anyone tried dry-web-roda with GraphQL? Any demo repo?
Anyone are using dry-web for their projects?
Oskar Szrajer
@gotar
I'm afraid except me or @timriley not too much persons use it on production :(
Tim Riley
@timriley
GraphQL applicability would be more about what persistence library you use, anyway. I haven’t heard of anyone doing it with rom-rb.
(and FWIW I’m looking at using hanami-router + hanami-controller as a front-end to dry-web/system for our future projects at work)
Nikita Shilnikov
@flash-gordon
@timriley awesome, thanks mate
David Dawson
@DangerDawson
@timriley you currently use roda? I am interested in why the switch to hanami-router?
Tim Riley
@timriley
From experience I realise I would prefer concrete classes/objects for each endpoint, rather than a big nested block.
Also, from a personal perspective, I’m trying to help with hanami development. This is a way for me to get on top of (some parts of) the framework.
David Dawson
@DangerDawson
Makes complete sense
Vasily Kolesnikov
@v-kolesnikov
@gotar I use dry-web-roda for a couple of my (production) projects.
I also found some inconvenience of using big blocks to describe routes and would love to see a better solution (maybe Hanami, but I'm not sure). Now I just divide my routes to separated files (named as a resource e.g. users.rb for /users/*).
Oskar Szrajer
@gotar
looks like I will try in new project a dry-web-roda + graphQL combo
we will see