Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
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
Ethan Turkeltaub
@ethnt
Hi, I'm looking for a little help with dry-validation. We're trying to massage some inputs from an external API to our internal API by mapping the external API's keys to our own keys. Is this something that's possible with dry-validation?
Igor Alexandrov
@igor-alexandrov
@ethnt I guess, you should look at Reform, it has an ability to map keys to model.
Vasily Kolesnikov
@v-kolesnikov

Is this something that's possible with dry-validation?

Probably not. At least dry-v should be used for other. Look at https://github.com/solnic/transproc, I use it for the same tasks as your.

Tim Riley
@timriley
@ethnt Yeah, I would do similar to @v-kolesnikov’s suggestion: put dry-validation as close as possible to the edge of the app, i.e. it would validate the input from the external API. After that point, you know you’re dealing with good data, so you could use transproc to transform it.
Ethan Turkeltaub
@ethnt
Thanks for the answers everyone. What we're trying to do is use dry-validation's schema to validate the inputs from an internal system, call out to one of two external APIs, massage the responses from them, and then map those responses to an internal model. The problem we're running into is that we'd like to share the schema between dry-validation and the internal model (currently using dry-struct) but we can't really
The internal model isn't database backed. We considered ActiveType but it didn't really jive with what we were trying to do
Ethan Turkeltaub
@ethnt
Transproc and Reform look very promising, thank you though! Maybe a combination is what we're looking for
Sean Winner
@swinner2
is there a solution to dry-rb/dry-validation#343 yet?
The ability to reuse a schema in a flat / non-nested manner (issue #204) following conventions already established, like so:
schema(EmailAddress::Schema::Create)
required(:email_address_id, Types::String).value(:str?)
Brice Sanchez
@bricesanchez
Hi all! I'm currently creating my first app with dry-transaction, How could i skip a step? How could i create reusable methods like helpers?
To skip a step, should i only use a guard condition at the beginning of the step ?
Tim Riley
@timriley
@bricesanchez good question! Would you mind posting on discourse.dry-rb.org? I’m not at a computer today but should be able to answer tonight.
Kris Leech
@krisleech
Is it not possible to override #initialize for dry-struct's. Unless I've got some typo it doesn't appear to be called:
  class Form < Dry::Struct
    attribute :name, Types::String

    def initialize(attrs = {})
      binding.pry # not called
      super.symbolize_keys
    end
  end
Okay I'm guessing transform_keys(&:to_sym) is the way to go.
Artemiy Solopov
@art-solopov
Hello everyone.
Is there any kind of guide to using dry-struct with dry-validation in a, well, DRY way?
As of now, it looks like I'll have to define the attribute names (and possibly types) twice, in the validation schema and in the struct itself...
Piotr Solnica
@solnic
@art-solopov hey, what's your use case?
Sean Winner
@swinner2
@art-solopov I am also interested in your question. I’ve been co-locating the schema and the struct since the key names need to be duplicated. I validate the params then use the output to instantiate the struct.
schema = Form::Schema.call(params)
Form.new(schema.output)
Piotr Solnica
@solnic
@swinner2 minor but : Form.new(schema.output) => Form.new(schema) because schema's result are coercible to a hash
Sean Winner
@swinner2
:thumbsup: @solnic thanks. I’m assuming the new dry-schema will help pull these pieces together, right?
usually I have to use schema.output.merge(errors: schema.errors) to get the errors on the form object to cooperate with simple_form
Piotr Solnica
@solnic
@swinner2 integrations with "form" helpers libs is a different topic actually
Artemiy Solopov
@art-solopov
@solnic I'm working on my web app (you can see the half-baked code at https://gitlab.com/art-solopov/billy-bones-2/tree/refactoring/)
I want to use Dry-Validation to validate stuff and to use Dry-Struct as intermediate form objects (mostly because it's easier to integrate with Rails helpers than hash-like validation results).
Currently I have to duplicate quite a lot of data (attribute names and types).
For example, here's app/schemas/bill_basic_schema.rb:
BillBasicSchema = Dry::Validation::Schema(build: false) do
  required(:period_month) { filled? & int? & included_in?(1..12) }
  required(:period_year) { filled? & int? & gt?(2010) }
  required(:cost) { filled? & float? & gt?(0) }
  optional(:paid_at) { filled? > date? }
  optional(:state) { filled? > included_in?(Bill.state.values) }
  optional(:payment_method_id) { filled? > int? }
  optional(:tags) { array? }
end
And here's the app/forms/bill_form.rb:
class BillForm < ApplicationForm
  attribute :period_month, Types::Params::Integer.default { Time.zone.today.month }
  attribute :period_year, Types::Params::Integer.default { Time.zone.today.year }
  attribute :cost, Types::Params::Float.default(0.0)
  attribute :paid_at, Types::Params::Date.optional.default(nil)
  attribute :state, Types::Coercible::String.default('init')
  attribute :payment_method_id, Types::Params::Integer.optional.default(nil)
  attribute :tags, Types::Coercible::Array.of(Types::Coercible::String).default([])

  SCHEMA = Dry::Validation.Params(BillBasicSchema)

  attr_accessor :errors

  def self.from_model(model)
    period = model.period || Time.zone.today
    attrs = model.values.slice(:cost, :state, :paid_at,
                               :payment_method_id, :tags)
              .merge(period_month: period.month, period_year: period.year)
    new(attrs)
  end

  def self.new_attrs(overrides = {})
    period = Time.zone.today
    overrides.reverse_merge(state: :init,
                            period_month: period.month,
                            period_year: period.year)
  end
end
choallin
@choallin
Hey guys! I have a strange problem with dry-validations... . I have a validate block in my scheme and, if I have an error in it I get the message that it fails.
But when I want to access the errors, I get the error TypeError (no implicit conversion of Hash into String)
I tried to access the errors with the errors and the messages methods but I get the same error everytime...
Kacper Pucek
@KacperPucek

Is it possible to use validate in combination with each? Let me show the example:

Dry::Validation.Params do
  required(:tickets).each do
    validate(allowed_quantity: %i(selling_strategy quantity)) do |selling_strategy, quantity|
      # Some logic for checking if quantity can be used
    end

    required(:price).filled(:int?)
    required(:quantity).filled(:int?)
    required(:selling_strategy).filled(:str?)
  end
end

While required checks are nicely nested under tickets, allowed_quantity always bubbles to the top. It would look like this:

{:tickets => { 0 => {:price => ["is missing"]}, :allowed_quantity => ["some msg]}

Any ideas how to nest this custom validation block as well? Cheers!