11–20 of 50 posts
Earlier quoted context omitted.
Well you can if you want. There's a lot of Ruby projects that are looking for contributions.
>Well you can if you want. Oh, yes, of course. But I am only willing to work for 6-7 hours a day, 5 days a week and my employer pays for them all. Working outside that... nah, no need.
But interactions are a plague. People start chaining interactions and very soon you have a maze of these things, with all the domain logic lost inside of these procedures and almost no POROs in sight.
Most of these complaints are, of course, not inherently the fault of these commands/operations/interactions, but they make it so easy to create these monstrosities that I have to put some of the blame on them.
SlackNotifier.notify("Welcome email sent to #{email_address}")
end
If you want Hanami to be an IoC framework, why still allow direct SlackNotifier to be injected to the action layer here ? I guess, lib/ folder should be loaded into Deps instead (Deps["slack_notifier"] ?
For me it's a shame that they doubled down on the "interactors" (which are now called operations?) pattern. I really like the containers system from `dry-rb` and overall how the routing/controller system works. I like the concept of multiple apps and slices as first class citizens. But interactions are a plague. People start chaining interactions and very soon you have a maze of these things, with all the domain logi…
For me it's a shame that they doubled down on the "interactors" (which are now called operations?) pattern. I really like the containers system from `dry-rb` and overall how the routing/controller system works. I like the concept of multiple apps and slices as first class citizens. But interactions are a plague. People start chaining interactions and very soon you have a maze of these things, with all the domain logi…
Hanami 2.0 doesn’t have any interactors
Guess that changes everything for me. Will definitely give it a try.
Earlier quoted context omitted.
Well you can if you want. There's a lot of Ruby projects that are looking for contributions.
>Well you can if you want. Oh, yes, of course. But I am only willing to work for 6-7 hours a day, 5 days a week and my employer pays for them all. Working outside that... nah, no need.
It looks clean because the developers are also the people behind dry-rb. However, I made one production service in Hanami and never again. They put clean syntax above all else. This results in a TON of metaprogramming with very weird results. There were times when a variable name I was using in my code was conflicting with a method called in one of the many `instance_evals` to achieve such "dryness" I really do like…
:-)
If your app uses Hanami and Zeitwerk, for example, breaking changes in Zeitwerk may REQUIRE you to update Zeitwerk before you can upgrade Hanami. Or, if dry-rb hasn't adopted the new version of Zeitwerk, you may be stuck on an old version of Zeitwerk, unable to update it. Depending on the nature of the breaking changes, working through this stuff could be a lot of work for a mature app.
Maybe the maintainers are nice and release patch versions for older major releases. I don't know. What I do know is that either way, there is likely to be a lot of maintenance burden somewhere unless these libraries have high stability guarantees.
I don't understand the Rubyist obsession with having a whole bunch of magic stuff just "happen" in your code. Magic is fine if the scope is narrow and well-defined. Ruby magic is often _entire app magic_, which means that it is hard to approach (because you need to understand how it works in many contexts). If that magic ever changes, there are a lot more places where it can break stuff.