Thank you so much!
So the issue is with dry-web then... should this be raised on the discussion forum?
I really like dry-w concept, but I use it not in a direct way. I have some projects (open and private as well) which built on top of dry-web-roda and at the end, in my latest project I don't use dry-web-roda as a dependency, instead I use its template. I have
system and lib dirs, use dry-system to manage components, use roda as a router and so on. But just without dry-w as a dependency. I doesn't mean I have something against dry-w, just share my experience.
@eliav-lavi Seems like you should use the following:
config.default_context = Container["view.context"]
In dry-view 0.5.x
@v-kolesnikov changing
context to default_context is something I already tried after sniffing around a bit in debug mode and just trying things out, but it leads to another error:NoMethodError: undefined method `for_rendering' for #<DwrTest::Main::View::Context:0x00007fd53fc59f38>
/Users/eliavlavi/.rvm/gems/ruby-2.5.3/gems/dry-view-0.5.4/lib/dry/view/rendering.rb:23:in `initialize'
/Users/eliavlavi/.rvm/gems/ruby-2.5.3/gems/dry-view-0.5.4/lib/dry/view/rendering.rb:7:in `new'
/Users/eliavlavi/.rvm/gems/ruby-2.5.3/gems/dry-view-0.5.4/lib/dry/view/rendering.rb:7:in `prepare'
...
127.0.0.1 - - [18/Jan/2019:10:47:25 +0200] "GET / HTTP/1.1" 500 151990 0.0265
Nor is it documented yet.
Context classes now need to inherit from Dry::View::Context
the
"< 0.5" is my addition, without it it didn't work
I’m going to yank it now
Yanked.
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
@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?
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)
@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 :(