@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
@solnic If I may intervene, one of my main problems with Hanami is that it creates an instance of an action per request.
What's your view of that aspect, if I may?
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?
@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
I think 1.x actions mutate their state, so it would make sense to get a new object each time
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
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 :)
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)?
getting rid of manual object creation in apps based on dry-system worked 1000x better than anything I tried before
@solnic did you manage to incorporate dry-system into an Hanami app and be pleased with it, if you have tried that?
(oh and I should mention I am a huge RSpec fan)
@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)
swapping routing front-ends in this architecture really is easy
@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 :(
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
endI'm getting the following error:
Dry::Transaction::InvalidResultError: step +transaction+ must return a Result objectI guess because the ActiveRecord::Rollback is not being rescued.
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
In essence, I want it to be strict.
@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
Hey @flash-gordon, not sure if you had the chance to check this dry-rb/dry-types#277 out? I think we're just waiting for your input. No hurry, though, just don't want the momentum to get lost.