Let’s learn and work together on Hanami at RubyConf 2024! 
Day two of this year’s RubyConf will feature a community hack day, where conference-goers can get together with maintainers to work together on contributions to Ruby OSS projects.
I’ll be bringing Hanami to this year’s hack day!
Who am I? I’m Tim Riley, the lead of the Hanami project. I’ve been driving the Hanami 2 development over the last 5+ years.
Who are you? You can be anyone at RubyConf! All are welcome! Regardless of your experience level, please come along and I can help you learn the Hanami ecosystem and put together your first contribution to the project.
This post will serve as your getting started guide to Hanami development, and a source of ideas for your contributions.
Getting started
Hanami projects are fairly typical Ruby projects. Here’s how you can get started for development:
- Clone the repo
- Run
bundle install - Run
bundle exec rake specto run the tests
That’s it! If there are any other specific requirements, these will be noted in each repo’s README.
Hanami consists of multiple repos. Your contribution will likely be in one of the following: hanami, cli, db, controller, router, view, assets, assets-js, rspec, webconsole.
Hanami also depends on gems in the dry-rb and rom-rb organisations.
Ideas
Watch this space! I’ll continue to add to it as RubyConf approaches.
General
Update the README in new Hanami apps with helpful instructions
Right now the README in new Hanami apps is fairly bare-bones. It could come with some more useful instructions for getting started with Hanami. Let’s get them in place!
Tidy up all inspect outputs
Some of our framework-level objects have rather large (and confronting!) #inspect outputs. These can get in the way, especially when interacting with objects in the console or in our error pages. Let’s slim these down and get them to a place where they help rather than hinder our users. (Hint: Hanami::View#inspect’s output is particularly thicc).
Memoize actions and views in the container, measure performance impact
Right now our app and slice containers return new instances of these objects every time they are fetched. Instead, we could have the container set up these components using the memoize: true option, which would mean the same object is returned each time. We expect this may bring some good performance improvements! Let’s make this small adjustment, and then measure the impact.
Add built-in i18n support to Hanami
Right now we don’t offer this. But it would be very helpful! To add this, we can create a first-party provider that sets up i18n for our users, with configuration allowing for i18n yml files in conventional locations (within the app and within each slice). Along with this, we’d need a helper method for accessing i18n translations inside views.
As a flow on from this, it would also mean we could start to offer other view helpers that depend on i18n, like Rails’ number_to_human.
CLI
Create a hanami generate provider command
Users only occasionally need to create providers. Having a generator to do this will help them remember the right syntax to do so, and could provide some helpful tips via code comments in the generated file.
Rationalise the output of all the hanami db commands
Right now these provide differently formatted output lines depending on whether their operations are timed or not. This makes for a disjointed experience. It would be better for this output to be simplified and made consistent. We don’t need the timing information. We also need clearer details certain commands.
Prevent file overwriting
Right now the CLI generators will overwrite existing files. This is dangerous behaviour, especially if existing files contain work from the user that is not yet committed to source control. We should fix this so it doesn’t happen and instead shows a helpful error message.
Provide more helpful output when unknown options given to a command
Right now when you provide an incorrect argument, you’ll see output like this:
❯ be hanami generate relation posts --fnorp
ERROR: "hanami generate relation" was called with arguments "posts --fnorp"
This should be more useful. It should show the details of the command and the options that are actually available.
Allow for third party code extending existing CLI commands to register their own specific options on those commands
Gems can enhance existing registered hanami CLI commands using Hanami::CLI.after "some_command", but they cannot add new options to the command. We should allow this.
Bring some 
pizazz to the CLI experience
Right now the user experience of the hanami CLI experience is fairly basic. We want Hanami to be a framework that brings both power and delight, and the CLI is our front door. This is a great chance to make it nicer!
For example, our hanami new output is fairly basic. This is the very first thing people see when they try Hanami. Can we bring some “wow” factor here?
And in general, look for anywhere we might provide more sparkle to our CLI outout
Database
Add more conventional APIs to rom-factory
We would like to integrate rom-factory with Hanami in the near future. Right now, however, using rom-factory is a little awkward due to its non-conventional APIs, such as Factory[:factory_name] to persist and return an object, and Factory.structs[:factory_name] to return an in-memory object only. These would be better as Factory.create(:factory_name) and Factory.build(:factory_name) instead.
Update rom-factory to support a configurable inflector
Right now, rom-factory’s inflector usage is hard-coded across multiple files (search for “inflector” to see). Instead, it should be possible to supply an inflector when creating/configuring the factory itself. This would allow a future Hanami integration to provide the Hanami app inflector.
Controller
Allow exception names represented as strings in Hanami::Action.handle_exception
See this issue: right now we require a proper Ruby exception class here, which means that users may need to require libraries that have nothing to do with actions, merely so they can rescue their exceptions. Using strings here would free users from having to have everything required at this point.
Zero-config cookie session configuration
Most users of Hanami web apps will need to set up cookie sessions. Requiring them to add their own config for this is a little bit of a hurdle, so it would be good if we could find a way for hanami to do this via some conventional ENV vars or similar.
Router
MissingActionError should show relative path instead of absolute path for suggested action
View
Provide a nicer Hanami::View::TemplateNotFoundError message
This error message is OK right now, but we could make it even more helpful by suggesting as closely as possible which file the user should be creating.
Docs and guides
Update our building a web app guide to set up some CSS/JS
Right now this guide doesn’t step through creating CSS or JS, and instead just points to the frontend assets guide for the user to figure things out for themselves. It would be good if we could instead add some basic CSS and JS as part of the getting started guide itself.
Help us make some “app recipes!”
If you’re more interested in direct user enablement, then you could just get started building a Hanami app and helping create examples/documentation for users about using Hanami with various tools. For example:
- Sidekiq + Hanami
- Rodauth + Hanami
- Shrine + Hanami
- A full CRUD example app
- And so on…