Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 15:43
    FioFiyo starred dry-rb/dry-types
  • 11:52
    flash-gordon commented #361
  • 07:09
    unixc3t starred dry-rb/dry-types
  • Oct 22 22:33
    patrickclery commented #361
  • Oct 22 21:12
    D1mon starred dry-rb/dry-matcher
  • Oct 22 15:44
    graudeejs starred dry-rb/dry-container
  • Oct 22 08:41
    esparta commented #366
  • Oct 22 08:39
    flash-gordon commented #366
  • Oct 22 08:39

    flash-gordon on master

    Fix error on Dry::Types::Array#… Merge pull request #366 from es… (compare)

  • Oct 22 08:39
    flash-gordon closed #366
  • Oct 22 08:38
    flash-gordon closed #362
  • Oct 22 08:38
    flash-gordon commented #362
  • Oct 22 08:37
    flash-gordon closed #361
  • Oct 22 08:37
    flash-gordon commented #361
  • Oct 22 07:48

    solnic on master

    Adding missing built-in predica… Merge pull request #65 from esp… Merge branch 'release-1.0' (compare)

  • Oct 22 07:47

    solnic on release-1.0

    Adding missing built-in predica… Merge pull request #65 from esp… (compare)

  • Oct 22 07:47
    solnic closed #65
  • Oct 22 07:29
    esparta opened #65
  • Oct 22 07:06
  • Oct 22 06:23
    robturtle starred dry-rb/dry-monads
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"
@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
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
Jaromír Červenka
@Cervajz
I'm in the process of converting GQL app from AR to ROM but on top of Rails. So far so good as I had validations and business logic in dry-* already. I have to be careful with GQL nested queries though - it was easier with AR to do so, but one could end up in a "circle of queries" if not being careful. Nesting with ROM is more visible and "terminated" at some point. Which I like.
Alexander
@cutalion
Hi, is there less "verbose" interface for custom rules in dry-validations?
Here is how I check "all or none" fields for location.
rule(location_provided: [:address, :latitude, :longitude]) do |address, latitude, longitude|
  (address.filled? & latitude.filled? & longitude.filled?) |
       (address.none? & latitude.none? & longitude.none?)
end

each attribute name repeated 4 times. Seems not readable.

I could extract internal code to some helper function like all_or_none(address, latitude, longitude)
but this will only reduce 1 mention of each name

Is it possible to use something like this?

rule(:location_provided) do |s| #s for schema
  all_or_none(s.address, s.latitude, s.longitude)
end
Alexander
@cutalion
Or maybe something like macros for high-level rules
rule(location_provided: [:address, :latitude, :longitude]).all_or_none