Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 10:29
    flash-gordon commented #375
  • 10:08
    wuarmin starred dry-rb/dry-configurable
  • 10:02
    dilcom commented #375
  • 10:02
    dilcom commented #375
  • 08:11
    flash-gordon commented #375
  • 07:54
    flash-gordon commented #115
  • 05:40
    wpzero starred dry-rb/dry-monads
  • 05:30
    dilcom opened #375
  • 02:18
    johnmaxwell edited #115
  • 02:18
    johnmaxwell edited #115
  • Dec 08 23:10
    johnmaxwell labeled #115
  • Dec 08 23:10
    johnmaxwell opened #115
  • Dec 07 14:03

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 10:01
    Travis dry-rb/dry-view (master) errored (636)
  • Dec 07 09:58
    Travis dry-rb/dry-view (master) errored (635)
  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

Tim Riley
@timriley
0.5.3 should work for you.
Sorry about that, @eliav-lavi
You’ll want to gem uninstall dry-view -v 0.5.4 and then re-bundle
Eliav Lavi
@eliav-lavi
No worries @timriley! I I guess that's not very trivial to coordinate seamless compatibility like that :) Really appreciate the work done here.
Piotr Solnica
@solnic
it's a bigger challenge when gems are in beta, after things settle it becomes much simpler
Piotr Solnica
@solnic
@v-kolesnikov re ditching dry-web-roda, it doesn't surprise me because this gem is really just a tiny integration between dry-system and roda, it can help people get up and running quickly but there's very little it actually provides (which is a wonderful thing, btw). given that we're now focusing more on hanami 2.0/3.0 effort, it's possible we'll discontinue dry-web* gems unless somebody would like to take over them
Eliav Lavi
@eliav-lavi
@solnic If I may intervene, one of my main problems with Hanami is that it creates an instance of an action per request. FooAction.new.call(args) - even if I can override the initialize method, as they describe, this is not how I want to do it, I want to have a single instance of those classes and just pass data through them.
What's your view of that aspect, if I may?
Jeff Dickey
@jdickey
@solnic :+1: That makes sense to me too. I remember poking at dry-web-roda when it was first published, and then going back to my own Rube Goldberg integration because I understood that and didn't see where d-w-r was trying to go, going forward. Tying up Dry + Hanami + ROM in the way that's been described over the last few months makes much more sense to me and my team, and we're excited to see where that goes
Tim Riley
@timriley
@eliav-lavi I’m not 100% sure how hanami actions work in 1.x, but in 2.0, whenever it comes out, what you describe will be possible
I think 1.x actions mutate their state, so it would make sense to get a new object each time
Eliav Lavi
@eliav-lavi
@timriley That's very good news!
Jeff Dickey
@jdickey
@eliav-lavi You're talking something more like Rails' Active Controller, where each action is a method on a class?
Eliav Lavi
@eliav-lavi
@jdickey not really, I just think the action class should have a single instance, created upon system boot. It should be immutable obviously. I actually do like the idea of one action per class, the Rails way is not my cup of tea here.
Piotr Solnica
@solnic
I can't say for sure but I remember Luca talking about actions becoming singletons that are "called" at runtime with input and they expect to return output (response object is being passed through and this one is mutable)
Jeff Dickey
@jdickey
The thing that initially sold us on Hanami, more than any other feature, was that each controller action is a separate class. Want shared behaviour? Extract it to a module that's included in each action. Explicit is more easily understood than implicit, and that's the basis for Clean Architecture to begin with. Minimise the number of places I have to look to understand what's going on in an individual piece of code
Eliav Lavi
@eliav-lavi
@jdickey no argue about that, completely valid. I like Hanami a lot.
Jeff Dickey
@jdickey

Minimise the number of places I have to look to understand what's going on in an individual piece of code.

...without burying me in a five-hundred-line piece of code with a score or three private methods, like too many Rails controllers I've had to do chainsaw surgery on over the years

Fine, then :)
Eliav Lavi
@eliav-lavi
@solnic it makes sense in general. I think the tendency to create what they call "service objects", that you instantiate and use at the same place, are a Ruby thing that actually creates a lot of troubles. This is the root of hard coded dependencies in many ways...
Piotr Solnica
@solnic
speaking about hanami actions, personally I would like to experiment in the future with a single-controller file with multiple actions as methods, that are "compiled" into standard classes behind the scenes, just for initial convenience. this approach works well in rom-rb and I think it's worth exploring
@eliav-lavi are you talking about FooService.new.do_stuff(params)?
Eliav Lavi
@eliav-lavi
Exactly.
Piotr Solnica
@solnic
IMO this is an anti-pattern, so I agree with you
getting rid of manual object creation in apps based on dry-system worked 1000x better than anything I tried before
Eliav Lavi
@eliav-lavi
And I believe this is SO widespread partially because of RSpec's allow_any_instance_of, which gives you the ability to unit test nevertheless. In Scala, for example, this is simply not possible... you just can't do that, so people don't.
@solnic did you manage to incorporate dry-system into an Hanami app and be pleased with it, if you have tried that?
Piotr Solnica
@solnic
@eliav-lavi I've only played with this idea and got it working, but I haven't built any production app with hanami/dry-system stack. IIRC Anton from hanami core uses hanami + dry-system in real apps.
re rspec, I so agree with you, I would say more - RSpec's crazy mocking capabilities has done more harm than good. I really wish RSpec's core team decided to trim that API to the very minimum.
(oh and I should mention I am a huge RSpec fan)
Eliav Lavi
@eliav-lavi
@solnic Would be interesting to see how he approaches that problem... Right now this kinda blocks me from adopting Hanami to my next project. Which leaves me kinda lost I guess - I feel like my best shot now is to assemble everything on my own, Roda\Sinatra for routing + ROM (I build an API, all jsons, no need for views at all)
Piotr Solnica
@solnic
@eliav-lavi if you build your app using dry-system with whatever else that you prefer and keep strong separation between the routing/http layer and your app layer, then I'm pretty damn sure porting it to hanami 2.0 will be easy
swapping routing front-ends in this architecture really is easy
Eliav Lavi
@eliav-lavi
@solnic yes, I am also a huge RSpec fan but indeed they, as many others, have taken the fact that Ruby is an interpretable, not complied, language, to a bad place. The thing is, it works OK for small CRUD apps but when you have bigger stuff with lots of logic, it's just one big procedural mess :(
Piotr Solnica
@solnic
there is one strong argument that one of the rspec folks said a while ago - rspec-mock can be extremely helpful when dealing with legacy apps
Eliav Lavi
@eliav-lavi
@solnic regarding your suggestion, yes that's my point I guess. I still have to figure out how to incorporate dry-system in my app exactly.
Piotr Solnica
@solnic
which is very true, however, you really gotta be a pro rspec user and know your stuff very well in order NOT to harm yourself :)
Pablo Crivella
@pablocrivella

Any idea how to make this work?

require "dry/container"

module Core
  class Container
    extend Dry::Container::Mixin

    register("transaction") do |input, &block|
      result = nil

      begin
        ActiveRecord::Base.transaction do
          result = block.call(Dry::Monads::Success(input))
          raise ActiveRecord::Rollback if result.failure?

          result
        end
      rescue ActiveRecord::Rollback
        require "pry"; binding.pry
        result
      end
    end
  end
end

I'm getting the following error:

Dry::Transaction::InvalidResultError: step +transaction+ must return a Result object

I guess because the ActiveRecord::Rollback is not being rescued.

Pablo Crivella
@pablocrivella
Okay… it was easier than excpected… sorry for the spamming :sweat_smile:
    register("transaction") do |input, &block|
      result = nil

      Account.transaction do
        result = block.call(Dry::Monads::Success(input))

        raise ActiveRecord::Rollback if result.failure?
      end

      result
    end
Grant Shangreaux
@gcentauri
haha i was going to say maybe the result wasn't always getting returned
i have a question on dry-validation... is it possible to export a JSON schema file based on a dry schema? I find the dry/ruby stuff much easier to read but my work still depends on JSON schemas
Tristan Mortimer
@Qwuke
Hey all, I was wondering whether or not anyone knew of any examples of dry-rb/dry-monads being used in an API client library - am curious how that type of error handling would look in a somewhat fleshed out project
Grant Shangreaux
@gcentauri
is it possible to write a dry predicate that depends on more than one value?
Kasper Sacharias Roos Eenberg
@kse
I use dry-validation for validating input, is there a way to fail if it encounters keys I have written a rule for?
In essence, I want it to be strict.
Alexandru Beu
@alexandrubeu
hey, I'm using dry stack and I have a question related to dry-container in relation with dry-system. Is it possible to have scoped per request dependencies? Thanks
Nikita Shilnikov
@flash-gordon
@alexandrubeu nothing working OOTB. You can create a container on every request, though, with a certain amount of effort this should be good enough. At least I did this, but now I'm experimenting on providing context-aware dependencies using a different approach. If it works fine (atm it appears so) I'm going to build another library for this, it's a matter of months
Alexandru Beu
@alexandrubeu
thanks a lot... I will try to create another container which will be handled by the web.rb hooks :before and :after
Nikita Shilnikov
@flash-gordon
btw, what do you want to add there?
Alexandru Beu
@alexandrubeu
I would like to inject some dependencies like a tenant which should be registered every time a request has arrived. Based on that fact I don't need to pass the param tenant in all my app
Nikita Shilnikov
@flash-gordon
exactly my case