Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Simon Schmid
@sled
mh so this gets me thinking, we have a document which can be in a "draft" mode, i.e a lot of optionals, no requirements - just type checking
and then the document is validated and put in a "validated" mode, same fields but with a lot of required attributes
Piotr Solnica
@solnic
sounds like a good use case for sub-types then
John Backus
@backus
So is this Kleisli gem dead? Doesn't seem like the maintainer is interested in it anymore
Piotr Solnica
@solnic
Probably. I dunno
Nikita Shilnikov
@flash-gordon
@backus I think you can ping author on Twitter or via email
Mb someone should fork the repo and republish it as a new gem
Ngan Pham
@ngan
@solnic I'm trying to create a service objects with good validation for input. And I think being able to check the type of a variable (beyond primitive types) would be nice
John Backus
@backus
Eh I'm not that interested in it. I just want to get it updated so that it doesn't monkey patch my ruby environment when I require dry-types :P
I do think dry-rb should fork it though
and reduce it down to the useful functionality without all of the haskell-wannabe syntax
Piotr Solnica
@solnic
We thought about it already
Piotr Solnica
@solnic
Either is fantastic but the rest is meh
dry-monads? :P
I actually thought about dry-fp project with some common abstractions that we use in many places
John Backus
@backus
Nice
dry-monad seems pretty good to me
I really think they will be more useful if the syntactic sugar is ditched
Piotr Solnica
@solnic
Me too
Even Either could be a bit simpler to use. >-> and fmap confused me more then once
John Backus
@backus
mhm

Could their >-> example

result = Right(3) >-> value {
  if value > 1
    Right(value + 3)
  else
    Left("value was less or equal than 1")
  end
} >-> value {
  if value % 2 == 0
    Right(value * 2)
  else
    Left("value was not even")
  end
}

just be re-written such that Right and Left provided the method #bind like so?

Right(3).bind do |value|
  if value > 1
    Right(value + 3)
  else
    Left("value was less or equal than 1")
  end
end.bind do |value|
  if value % 2 == 0
    Right(value * 2)
  else
    Left("value was not even")
  end
end
Tim Riley
@timriley
I’d be up for us having a small set of useful things in either dry-fp or dry-monads
I’m really not the biggest fan of kleisli’s >-> trickery. It makes chaining hard in a lot of cases, I’ve found.
John Backus
@backus
Alright so I can define a dry-validation rule that depends on other values
I can also define a schema that works with arrays as input
But can I define a rule for a value in an array which is dependent on the entire array
For example, can I write a validation that says that a value is not repeated in an array
John Backus
@backus
Also am I missing something here or is this a bug?
require 'dry/validation'
require 'dry/validation/version'

Dry::Validation::VERSION # => "0.7.4"

schema1 = Dry::Validation.Schema do
  key(:thing).required(:unique?)

  configure do
    config.messages_file = 'custom_errors.yml'

    def unique?(array)
      array.uniq.size == array.size
    end
  end
end

schema2 = Dry::Validation.Schema do
  key(:thing).required(:unique?)

  key(:thing).each do
    inclusion?(%w[foo bar])
  end

  configure do
    config.messages_file = 'custom_errors.yml'

    def unique?(array)
      array.uniq.size == array.size
    end
  end
end

bad_value      = %w[foo wtf bar]
repeated_value = %w[foo bar foo]

schema1.call(thing: bad_value).messages[:thing]      # => nil
schema1.call(thing: repeated_value).messages[:thing] # => ["must not repeat values"]

schema2.call(thing: bad_value).messages[:thing]      # => {1=>["must be one of: foo, bar"]}
schema2.call(thing: repeated_value).messages[:thing] # => nil
only difference between schema1 and schema2 is the added inclusion? rule within each
Benjamin Klotz
@tak1n
@backus I had such similar cases too, but was not sure if I made smth wrong or not
Piotr Solnica
@solnic
@backus specifying same key twice will override other rules
Each applies rules to each value, so the way you wrote it is not what you want
Oh wait, it is. Sorry (in pre coffee mode)
John Backus
@backus
What would that look like then @solnic? Like so?
key(:thing).required(:unique?).each do
  inclusion?(%w[foo bar])
end
Piotr Solnica
@solnic
this will work in next version, atm I don’t think this is supported
required(:unique?) returns Schema::Rule object which doesn’t support each, IIRC
@backus btw key(:thing).each(inclusion: …) is better, use blocks only when you want ORs
ORs or schemas*
Tim Riley
@timriley
@solnic something I'd like to do in the next little while is change dry-view Layout's "root" config into an array of paths, so we can package up gems with view templates (like our paginator) and have them available to use within dry-web apps. Does that seem good with you, in principle?
I think you'd still configure the paths yourself manually, for each of your layout classes. That way you can be explicit about which gems' view paths you care to include (and also it means we avoid global state).
Piotr Solnica
@solnic
@timriley yes sounds good
Tim Riley
@timriley
Great :)
I want to start avoiding copy/paste code between our apps in situations where it's clear some things can be gem-ified.
Tim Cooper
@coop

@solnic have you thought about supporting unknown keys with dry-v? This is the JSON payload of one of the APIs that we don’t own:

{
  "RpYCgWVGkNyRk3JsPUj9Hzp_CLedN5xM": {
    "name": “Bedroom"
  },
  # … more hashes ...
}

If we were in control of the API I’d move the id into the payload and just have an array but unfortunately it is supplied by a third party.

Tim Riley
@timriley
Not answering your question directly, but you could make it work by putting a mapper in front to rearrange those into a normalised form?
Also, what an... interesting API structure
:wink:
Tim Cooper
@coop
Good call @timriley.
Piotr Solnica
@solnic
yeah I would map it