dry-rb/chat

WE MOVED TO ZULIP => https://dry-rb.zulipchat.com <=

Luca Guidi

@jodosha

:100: :star2: :confetti_ball:

Piotr Solnica

@solnic

@jodosha :dancers:

Piotr Solnica

@solnic

@AMHOL thoughts on how to tackle complex error messages when you need more data than just input for a rule?

Andy Holland

@AMHOL

Not sure I understand fully, do you have an example?

Piotr Solnica

@solnic

ie you want to generate a message and provide a list of possible values that are dynamic, so you can’t hardcode it in the schema

basically every use case where a message needs data that come from some external source

Andy Holland

@AMHOL

I don't think we should do that

Piotr Solnica

@solnic

but it’s needed :)

Andy Holland

@AMHOL

lol

Piotr Solnica

@solnic

I told you I have all kinds of validation use cases :)

I have a couple of messages that need to do extra db lookups to provide meaningful feedback

Andy Holland

@AMHOL

What if there's a list of 500 values returned?

Piotr Solnica

@solnic

don’t get stuck on this silly example :)

it’s your job to construct that message, not dry-v's

but we need an interface to allow that

that’s what I’m asking

basically an equivalent of :message option in AM::V

with the exception of “option” part, because options in dsl are a horrible horrible idea (I’ll be repeating that all the time)

Andy Holland

@AMHOL

Shouldn't they be custom validations/integrations?

Piotr Solnica

@solnic

well, you could provide your own Messages implementation, subclass one of the built-in ones, and have a customized lookup (or whatever it’s gonna be called eventually)

Andy Holland

@AMHOL

Sorry, think I still don't understand exactly what you're asking :laughing:

Piotr Solnica

@solnic

@AMHOL you define a rule ie key(:book) { |book| book.publish? } and that predicate returns false when a system-level setting “publishing_turned_off” is set and it needs to set a message “sorry, but book publishing is turned off until %{date}” and date is retrieved from the database.

so it’s a dynamic validation that changes over time and needs a completely dynamic error message that requires data from an external system (a db)

Andy Holland

@AMHOL

Hmm, not sure without options hash lol

Piotr Solnica

@solnic

@AMHOL I’ll figure something out :muscle:

Andy Holland

@AMHOL

I'm sure you will

Hannes Nevalainen

@kwando

@solnic I'd like to inject a custom "key mapper" function to a form validation schema

for instance if my input hash has uppercase keys I would like the mapper to downcase them

Hannes Nevalainen

@kwando

class MySchema < Dry::Validation::Schema::Form
  key(:database_url){ |f| f.filled? }
end

schema = MySchema.new(key_map: -> x { x.to_s.downcase })
schema.call({'DATABASE_URL' => '<url to database>'}).params #=> {database_url: '<url to database>'}

Piotr Solnica

@solnic

@kwando sorry schema is not a data mapper

Hannes Nevalainen

@kwando

buzz, wrong answer

I understand =)

Piotr Solnica

@solnic

I'd give you a better explanation but I'm not feeling well today so my brain is kind of partially working

Hannes Nevalainen

@kwando

@solnic no worries =)

take care, do some rest

Piotr Solnica

@solnic

That is my plan

Vojtěch Kusý

@wojtha

Hi there. I finally found gitter chat for DryRb :) big :+1: for all the components.

I've played with AutoInject last night and created 3 more DI strategies for it. What do you guys @solnic @AMHOL think?

The code is here: https://gist.github.com/wojtha/b9730d108625e04a0642

Andy Holland

@AMHOL

@wojtha not sure about the getter/setter inject, but the key inject is something me and @solnic have discussed in the past

Was thinking of an interface more like include MyApp::Inject(messenger: 'message.store') myself

Would be good to see what @solnic thinks though

I haven't really worked on that gem

Vojtěch Kusý

@wojtha

Yeah. Hash init came to my mind as well. But for now I sticked with AutoInject's default init.

For getter/setter: these are fallbacks for Rails controllers or similar objects as I wrote in the description.

Where constructor DI is impossible

But I think that setter DI is better than no DI at all...

Kind of shade of gray :smile:

Where communities thrive

People

Repo info

Activity