This is some feedback, specially addressed to @timriley, about new changes introduced to dry-view.
First of all, let me thank you and all the
dry-rb team for the great effort you are doing developing a view layer with a really well thought architecture. I think it can contribute a lot in the ruby community.
I’m using master branch in a real project, so I hope this feedback can help you. Of course, I’m going to address the aspects I would do in a different way. The other 99% is perfect in my view
As I already said in the repo, I fear that while we are doing
dry-viewmore powerful, we are losing the easy to test all its components in isolation. I think this is mainly true for parts and scopes. Maybe with a bit of effort changing the way dependencies are injected to builders we could leave the users to create objects with no overloaded initializers. I haven’t thought about the actual implementation, though.
Sometimes I feel I need too much ceremony for simple things. Imagine I just want to define a very simple method for a view scope. Right now I have to create a new scope class and configure it. Maybe we could introduce some DSL to easy the creation of anonymous scope and context classes:
Now I’m doing:
class MyController < Dry::View::Controller config.scope = Class.new(Dry::View::Scope) do def my_tiny_method # .. end end # ... end
Maybe we could do something like:
class MyController < Dry::View::Controller config.scope do def my_tiny_method # .. end end # ... end
I think this would require some change in
dry-configurable, but otherwise we could do with a lambda:
class MyController < Dry::View::Controller config.scope = lambda do def my_tiny_method # .. end end # ... end
There is an inconsistency in configuring scopes as classes and contexts as instances. Maybe it is due also to overloaded initializers in scopes.
As said in the PR adding customizable scopes:
I’m very excited to see the addition of scopes, because it means we now have an appropriate place for every kind of view behaviour, whether it’s global (context!), specific to a particular value (parts!) or specific to a particular controller or template (scopes!).
I find the last statement about
specific to a particular controller or template (scopes!) a bit confusing about what you could already do in the controller itself. I mean, in the controller you already have the possibility to add logic particular to itself through exposures. They can be overriden when
#call is invoked, but anyway they have the same purpose than custom scopes. The difference is that scopes can access the actual context in use, while a controller can only access the configured context. But maybe what we should do is change the controller so that it has access to it. Otherwise it is a bit confusing what you should put as exposure or as scope method.
Of course, my knowledge is very limited and only achieved through use and surely there are good reasons to do those things differently, but I thought that a bit of feedback could be welcomed.