Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Simon Schmid
@sled
@solnic but how to handle these permutations? If I have a struct with 3-4 optionals, I'd have to create 4! different variations
also a common scenario is to save "incomplete" forms (e.g auto-saving)
Piotr Solnica
@solnic
I don’t use structs along with forms
I use structs to represent specific concepts in a system, and treat them as values
Simon Schmid
@sled
do you have an example what is meant by a "concept" ? :)
Piotr Solnica
@solnic
a product, a user, a product with a category, a list of products etc
Dung Nguyen
@mmeeoorroo
I have a scenario where I need optional types. When a user delete a product, the app just marks the product as deleted, and tracks that user with attribute :deleted_by, User. That field is nil until the product is deleted
could you give a suggestion on that case?
Simon Schmid
@sled
this is where the permutation starts, i.e Product, ProductWithCategory, DeletedProduct, DeletedProductWithCategory
Piotr Solnica
@solnic
I don’t have a generic answer or suggestion, because it depends on the application domain. I would definitely not used names like FooWithoutBar though.
you need to look at what your application is doing and in which contexts things are needed, these should give you good hints how to name things
if you have contexts where you have all products, including deleted ones, then you can have optional deleted_by I suppose
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