Hi! Until I read Explicit view dependencies, I had no idea that views were exposed to action through the regular dry-container machinery. In hindsight, that makes a ton of sense, but it took me a while to understand that.
That being said, I would argue that it would be very useful for newcomers (like myself) to explicitly include the view by default in generated actions. This would remove magic from the system, and allow us to see how views are handled. At the same time, it would teach people how to rename dependencies, 2-for-the-price-of-1!
I’m talking about adding 2 lines to the template that generates actions, essentially:
class Index < Bookshelf::Action
include Deps[view: "views.books.index"]
def handle(request, response)
end
end
2 lines: include ..., and a blank line
The generator would have to respect --skip-view, but otherwise, that’s all I’m talking about. If people are willing to have that by default in their actions, I’m willing to make the needed change.
A downside to doing this would be that by including this line of boilerplate code in every Action, users would assume it’s necessary. After all, why else would we generate a redundant line of code? For that reason, I don’t support this change.
It won’t happen for a while since there are higher priority tasks but I would like to add a “beginner mode” to Hanami apps, which would generate more verbose files (likely all explanatory comments though, not executable code).
Did you go through the Getting Started “Building A Web App” guide? If so, maybe we should emphasize this bit of framework glue in there.
I appreciate you bringing this feedback and suggestion forward, @francois1, thank you!
In this case, however, I’d like us to stick with the automatically provided view. One of our goals with Hanami 2 is to provide streamlined first touch experiences and minimise boilerplate where possible, and this is one such case.
The Deps mixin is so central to how Hanami works that I think our users will quickly come to understand it, even without these reminders in the generated actions. Users are going to want to introduce an a repo or an operation dependency into these actions, so they’ll reach for Deps at that point. And for typical actions (where the counterpart view is all the user needs), this will keep the list of deps smaller and more meaningful.
I am sure our docs can be improved, though, so if you have any thoughts about how we can make things clearer on that front, I’d love to hear them!
Thanks again, this kind of feedback is really important, so I hope our responses here don’t discourage you from sharing more in the future
Did you go through the Getting Started “Building A Web App” guide? If so, maybe we should emphasize this bit of framework glue in there.
I did read the 2.2 Getting Started page as well as V2.2: Building a web app pages from top-to-bottom. Then, I started coding. As I needed to, I referred back to the 2.2 Guide. One way this feature could have been exposed in the Guide is in the 404 section, where the book ID is not found. We could rewrite the section to use a separate view, rendering a Search page for example. Alternatively, we could render a file, a static 404 page.
Thanks again, this kind of feedback is really important, so I hope our responses here don’t discourage you from sharing more in the future
No, this isn’t discouraging me. I understand how feature development works, and that there is a cost for everything. I still have a couple of things I want to discuss, or issues I want to report. More to come!
