Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 14:38

    dry-bot on master

    [devtools] sync configs (compare)

  • 14:38

    dry-bot on master

    [devtools] sync configs (compare)

  • 14:38

    dry-bot on master

    [devtools] sync configs (compare)

  • 14:38

    dry-bot on master

    [devtools] sync configs (compare)

  • 14:38

    dry-bot on master

    [devtools] sync configs (compare)

  • 14:37

    dry-bot on master

    [devtools] sync configs (compare)

  • 14:37

    dry-bot on master

    [devtools] sync configs (compare)

  • 14:37

    dry-bot on master

    [devtools] sync configs (compare)

  • 14:37

    dry-bot on master

    [devtools] sync configs (compare)

  • 14:37

    dry-bot on master

    [devtools] sync configs (compare)

  • 14:15

    dry-bot on master

    [devtools] update CHANGELOG.md (compare)

  • 14:15

    flash-gordon on master

    Fix YAML syntax (compare)

  • 14:10

    flash-gordon on master

    gitignore .vscode Update changelog.yml (compare)

  • 14:02

    flash-gordon on fix-key-optional

    (compare)

  • 14:02

    flash-gordon on master

    Fix Schema::Key#optional It us… Merge pull request #385 from dr… (compare)

  • 14:02
    flash-gordon closed #385
  • 13:57
    dry-bot commented #385
  • 13:55
    flash-gordon opened #385
  • 13:54

    flash-gordon on fix-key-optional

    Fix Schema::Key#optional It us… (compare)

  • 13:54

    dry-bot on master

    [devtools] sync configs (compare)

Andy Holland
@AMHOL
So like:
class MyClass
  include Dry::Dependencies[:one, :two, :three]
end
Piotr Solnica
@solnic
right, sth like that
Andy Holland
@AMHOL
Cool, makes sense
I'll change that later
Initialize or Constructor then?
My one concern is that the visibility modifier will look weird with that
class MyClass
  include Dry::Dependencies[:one, :two, :three, visibility: :private]
end
Piotr Solnica
@solnic
include Dry::Dependencies::Private[:one, :two]
Andy Holland
@AMHOL
That could work
Andy Holland
@AMHOL
@solnic, thinking about that interface, it won't work with inheritance
ATM I can do:
class BaseController
  include Dry::Dependencies
  dependencies :app
end
class UsersController < BaseController
  dependencies :repo, :validator #, ...
end
UsersController.new(app, repo, validator)
Andy Holland
@AMHOL
Thinking of changing dry-validator to dry-validation and something like this: https://gist.github.com/AMHOL/fdf0a90292914ad758ec
Would be good to get some opinions though
Andy Holland
@AMHOL
Ahh, that wont work
Piotr Solnica
@solnic
@AMHOL I like dry-validation more :)
@AMHOL I was just looking at roda-flow again, it looks really cool I gotta say, it feels like a nice way of configuring your routing in a way that you simply point which objects are going to handle certain requests and what kind of input they need
Andy Holland
@AMHOL
Cool, me too, will merge it soon
Piotr Solnica
@solnic
I’m only worried that bigger apps will be hard to read due to nested blocks, I wonder how this could be improved
just slicing things into pieces would be enough
btw I’m gonna start working on the book in the upcoming week(s)
Andy Holland
@AMHOL
Yeah, roda already has a plugin for multiple routing blocks :)
Piotr Solnica
@solnic
so I’ll start putting together rodakase
first things I need to figure out is dir/file organization for it
Andy Holland
@AMHOL
Cool, looking forward to seeing what you come up with
Have a look at that repo i gave you access too
Piotr Solnica
@solnic
will do
Andy Holland
@AMHOL
Cool :)
Piotr Solnica
@solnic
I’m thinking about an auto-loading container, where it infers deps from a dir structure
my container has grown into lots of things but it’s Foo.new in 90% of the cases
Andy Holland
@AMHOL
That would be interesting
If we had auto curry we could always new up and then just configure the arguments
Although i guess instantiation isnt always what you want
Piotr Solnica
@solnic
@AMHOL I don’t like two things in roda-flow
idea of controllers and messing with response object
Andy Holland
@AMHOL
Yeah, thats just in the example tbf, not actually part of the lib
Thats how i use ut tho
Piotr Solnica
@solnic
my motivation is to decouple my app’s code from 1) persistence 2) http stuff
Andy Holland
@AMHOL
Btw i used roda flow at work on a small, db hitting microservice, get 14ms response times
Piotr Solnica
@solnic
nice!
Andy Holland
@AMHOL
Perhaps i will see the light when i see your rodakase
Tim Riley
@timriley
Trying to stay ahead of the curve and use Dry::Data as a form attributes object
ended up needing to build a shim like this:
class FormAttributes < Dry::Data::Struct
  def self.new(attributes)
    schema_defaults = schema.keys.map { |key| [key, nil] }.to_h

    super(schema_defaults.merge(Hash(attributes)))
  end

  def [](attribute_name)
    send(attribute_name)
  end
end
Just so it's not so strict about missing values when initializing
and #[] in place so I can use it with a ROM::Model::Validator
Tim Riley
@timriley
Him, except I can't use a Dry::Data::Struct as an input for a ROM command
Tim Riley
@timriley
I handled it this way in the interim:
App.register "transformations.to_h" do |input|
  input.to_h
end

App.register("transactions.sign_up_customer") do
  CallSheet(container: App) do
    map :process, with: "attributes.customer_sign_up"
    try :validate, with: "validators.customer", catch: ROM::Model::ValidationError
    map :prepare_for_persist, with: "transformations.to_h"
    tee :persist, with: "persistence.commands.create_customer"
  end
end
Added a #to_h to that FormAttributes class and that prepare_for_persiststep in the business transaction.
Does not feel ideal, but it works for now at least ¯_(ツ)_/¯