dry-rb/chat

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

Piotr Solnica

@solnic

I never used as a schema as a separate step

Andy Holland

@AMHOL

Ahh OK

You just use them in commands?

Piotr Solnica

@solnic

it's always an object that uses a schema internally and typically talks to a db through a repo or command or sutin

Andy Holland

@AMHOL

That makes sense

Piotr Solnica

@solnic

a...service object :P

one thing I still don't like is that this still mixes an http-specific schema with a lower-level app stuff

not sure how to make this nicer

w/o any duplication

Andy Holland

@AMHOL

Still not sure about the not registering them, it's still a dependency, but I don't have experience using dry-component yet

A separate transaction step? :joy:

Piotr Solnica

@solnic

@AMHOL for me it's not an abstract dependency, that's where I draw the line

think about an ActiveRecord model, it's also a boundary, and a really huge one, everywhere your code references an AR model it makes it clear that a given part of your app is coupled to a database

it's the same here, everywhere you use a schema that validates data coming from an http request it's pretty clear that this is part of your system that deals with http stuff

fwiw you could treat that as an abstract concept and only rely on its interface but I think it's an overkill

Andy Holland

@AMHOL

Yeah, I've backed myself into a corner many times trying to be too strict about things, and past experience would indicate that when I disagree with you I'm wrong lol

But I was still thinking in terms of the interface

Still not sure on that one, will have to try it out sometime I guess

Piotr Solnica

@solnic

well, we can both be right :D

I can make dry-v schemas work with auto-registration, but I don't want to ;)

Andy Holland

@AMHOL

BTW, what do you think of pre-configuring a key mapping in component?

Piotr Solnica

@solnic

wdym?

Andy Holland

@AMHOL

To allow registration under keys that don't have any relation to the class name

Piotr Solnica

@solnic

yeah we can use some configurable strategies for figuring this out

Andy Holland

@AMHOL

sth like

Dry::Component.configure do |config|
  config.mapping = {
    'user_validator' => 'users.validator'
  }
end

Then when it loads UserValidator it registers under users.validator

Rather than just computing keys from the constant name

It's a bad example, but the idea is that it allows for more abstract keys

Andy Holland

@AMHOL

Or perhaps just allow for a custom component loader

Piotr Solnica

@solnic

we can have a configurable object that takes

yeah we can easily do that

we probably should :)

Andy Holland

@AMHOL

:+1:

Tim Riley

@timriley

@gotar I'll be at work in 40 minutes - will look into this stuff for you right away

@solnic I don't quite see how the explicit require and accessing an object via a constant implies it's a boundary enforcer... Repos also demarcate boundaries, for example, but we don't do it for those...

Piotr Solnica

@solnic

not really an enforcer, just a signal that it's a concrete dependency being a boundary

repos are objects because it's better to have them as abstract stuff, this is 100 x bigger than a small object validating data (well ok a schema is big but not even close to the size of a repo object giving you access to data in your db including data mutation interfaces)

besides if these were not objects we would have to stick globals like db connections to classes etc, do-not-like

Tim Riley

@timriley

So concrete dependency == something that's just not another internal object in our app's core, something a bit more "foreign"

Is that kinda what you're saying?

Piotr Solnica

@solnic

wdym by "foreign"?

Tim Riley

@timriley

Foreign as is not quite like the other objects that comprise our app's core behavior, all of which are in the container. Foreign as in a bit like using another gem, even.

Piotr Solnica

@solnic

haven't thought about it like that

Tim Riley

@timriley

I can't equate it to the explicit require etc. we need for instantiatiiself value objects, because this is still a functional object and could be in our container

Piotr Solnica

@solnic

foreign as in external to the app's container, yes, of course

Tim Riley

@timriley

Yeah, that's what I meant

Piotr Solnica

@solnic

I think about schemas as types too

Tim Riley

@timriley

I'm gonna need to come up with a different injection scenario for my talk, haha

Piotr Solnica

@solnic

it's an fp object that responds to call but it also very strictly defines a very specific type of data that your app deals with

Tim Riley

@timriley

Yeah, I think I'm starting to get you now

Where communities thrive

People

Repo info

Activity