dry-rb/chat

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

Tim Riley

@timriley

@backus can do now

John Backus

@backus

Thanks :)

Tim Riley

@timriley

There you go

John Backus

@backus

Thanks!

Nick Sutterer

@apotonick

@timriley i'm planning an API in Operation a la Op.(params, user_repo: ...), so one positional, and the rest kw args. will that work with auto_inject/initialize?

Tim Riley

@timriley

@apotonick Not with any of the existing injection strategies, no

We keep runtime things like “params” totally away from the initializer so far

You could probably build an injection strategy that’ll let you pass params through and look to the second arg/kwargs for the deps, though

It’d be a bit of a divergance from what we’ve done so far - all the injection strategies are around providing deps as instance variables via the initializer - so it might take a bit of experimenting

Nick Sutterer

@apotonick

oh no, so will it be really hard to implement?

Tim Riley

@timriley

I don’t think it’d be “really hard”, no.

It’d just need some working out, since it’s slightly off the path we’ve trod so far.

Nick Sutterer

@apotonick

because, we don't want instances to stick around, hence the Op.() semantics everywhere (cells, trailblazer, soon reform, etc)

Tim Riley

@timriley

However, dry-auto_inject is now built so that you can provide your injection strategies, so at least it’s modularised enough to allow you to do this.

Nick Sutterer

@apotonick

could you help me implementing that?

the semantic is like (runtime parameters, kw: args, for: dependency, injection: true)

Tim Riley

@timriley

It’d be like https://github.com/dry-rb/dry-auto_inject/blob/master/lib/dry/auto_inject/strategies/constructor.rb, except instead of defining .new and #initialize (which is done by subclasses here), you’d just define .call

Nick Sutterer

@apotonick

uhm, wait, we still need an initializer

Tim Riley

@timriley

oh what?

oh, .call(foo, bar) effectively goes .new(something_here_maybe).call(foo, bar) or something?

Nick Sutterer

@apotonick

.call(foo, bar) would do .new(foo, bar).call(foo, bar) i guess

simply passes it to both methods

Tim Riley

@timriley

why would you want it going to both?

Nick Sutterer

@apotonick

because in new, the polymorphic builder is called and the programmer might need arbitrary data to decide what to build

actually... not sure if we'd need bar in call, you're very right

the API has been around for 2 years now, all i want is to make it work with auto_inject/initialize so we can hook our objects into dry and vice-versa

Tim Riley

@timriley

anyway, so this sounds like it actually just a case of constructor dependency injection after all

so you probably want some variation of the Kwargs strategy (https://github.com/dry-rb/dry-auto_inject/blob/master/lib/dry/auto_inject/strategies/kwargs.rb)

Nick Sutterer

@apotonick

"variation"?

Tim Riley

@timriley

except you’d look for the kwargs on the second arg

and you’d just pass through/assign the first arg, your “params”

Nick Sutterer

@apotonick

i'll have a look, going on a trip now. thanks for your help brother

Tim Riley

@timriley

:+1:

Alternatively, you could just give your params a “special” arg name

e.g. params: and then just go kwargs for everything

Tim Riley

@timriley

params would be in that case a “dependency” that must always be provided manually, rather than looked up by any auto-injection system

I’m not sure if that feels good or not, though

heh

Nikita Shilnikov

@flash-gordon

@backus sure man, no problem. I was actually about it, but then I dug a bit deeper and found there was no spec for callable defaults so considered this behavior as a bug/overlook. So if you have any strong dependencies on some behavior, be sure it's covered with specs. Anyway, I'll cc you next time in any case :)

John Backus

@backus

Thanks

Yeah I'm not too worried and I think I specified our needed behavior pretty closely

Nick Sutterer

@apotonick

@timriley i have the :params kw name ATM but it .. sucks. it feels too clumsy

Andrew Kozin

@nepalez

@jmgarnier if you're planning heavily use reader: :private as a pattern, then you would like new using method in dry-initializer:
https://github.com/dry-rb/dry-initializer/releases/tag/v0.7.0

Jean-Michel Garnier

@jmgarnier

Thanks @nepalez Things move very fast in dry-rb word, thank you for the notification :)

Tom Willis

@twillis

Hey all, was upgrading to the 0.10 series from the 0.9 series and I'm getting errors in the schemas that use rules with custom predicates...

"ArgumentError: unique_npi_number? predicate arity is invalid"

    configure do
      def unique_npi_number?(id, org_uid, npi_number)
        return true if npi_number.nil?
        existing_provider = Provider.find(org_uid: org_uid, npi_number: npi_number)
        if existing_provider && existing_provider[:provider_uid] != id
          false
        else
          true
        end
      end
    end

   ...

    rule(unique_npi_number: [:id, :org_uid, :npi_number]) do |id, org_uid, npi_number|
      npi_number.unique_npi_number?(npi_number, org_uid, id)
    end

was working just fine on the 0.9 series

Christopher Dennl-Ortega Arrieta

@cdennl

@twillis you can now define arbitrary validation rules, check the changelog on 0.10. some stuff changed

@twillis and you put in 4 arguments to a predicate which takes 3

@twillis you can omit the npi_number argument at the function call

npi_number.unique_npi_number?(org_uid, id) should do the trick

Where communities thrive

People

Repo info

Activity