# Hanami hack day at RubyConf 2024

**URL:** <https://discourse.hanakai.org/t/hanami-hack-day-at-rubyconf-2024/1051>\
**Category:** general\
**Created:** [November 1, 2024, 11:27am UTC](https://discourse.hanakai.org/t/hanami-hack-day-at-rubyconf-2024/1051 "2024-11-01T11:27:25Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![timriley](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.hanakai.org/timriley/32/621_2.png) [@timriley](https://discourse.hanakai.org/u/timriley)\
**Post date:** [November 1, 2024, 11:27am UTC](https://discourse.hanakai.org/t/hanami-hack-day-at-rubyconf-2024/1051/1 "2024-11-01T11:27:25Z")

</div>

_Let’s learn and work together on Hanami at [RubyConf](https://rubyconf.org) 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](https://timriley.info), 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:

1. Clone the repo
2. Run `bundle install`
3. Run `bundle exec rake spec` to 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](https://github.com/hanami/hanami), [cli](https://github.com/hanami/cli), [db](https://github.com/hanami/db), [controller](https://github.com/hanami/controller), [router](https://github.com/hanami/router), [view](https://github.com/hanami/view), [assets](https://github.com/hanami/assets), [assets-js](https://github.com/hanami/assets-js), [rspec](https://github.com/hanami/rspec), [webconsole](https://github.com/hanami/webconsole).

Hanami also depends on gems in the [dry-rb](https://github.com/dry-rb) and [rom-rb](https://github.com/rom-rb) organisations.

## Ideas

### 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!

_Done in [hanami/cli#273](https://github.com/hanami/cli/pull/273), though further improvements could still be made._

#### 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](https://github.com/hanami/cli/issues/181)

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:

```auto
❯ 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](https://github.com/rom-rb/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.

_Done in [rom-rb/rom-factory#92](https://github.com/rom-rb/rom-factory/pull/92)._

#### Update rom-factory to support a configurable inflector

Right now, [rom-factory](https://github.com/rom-rb/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](https://github.com/hanami/controller/issues/432): 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](https://github.com/hanami/hanami/issues/1438)

### 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](https://guides.hanamirb.org/v2.2/introduction/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…

---

<div class="post-metadata">

**Author:** ![cflipse](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.hanakai.org/cflipse/32/778_2.png) [@cflipse](https://discourse.hanakai.org/u/cflipse)\
**Post date:** [November 14, 2024, 9:09pm UTC](https://discourse.hanakai.org/t/hanami-hack-day-at-rubyconf-2024/1051/2 "2024-11-14T21:09:58Z")

</div>

an update for `rom-factory` … turns out, I don’t have perms on that repo, so gotta wait for @solnic or @flashgordan

> <https://github.com/rom-rb/rom-factory/pull/92>
>
> This adds two methods to the \`Factories\` instances:
> 
> \* \`Factory.create\` as an al…ias of \`Factory.\[\]\`
> \* \`Factory.build\` as a delgator to \`Factory.structs#\[\]\`
> 
> These are more commonly expected methods for interacting with a Factory, 
> and are slightly more expressive when encountering thier usage.
> 
> ref: https://discourse.hanakai.org/t/hanami-hack-day-at-rubyconf-2024/1051
> 
> This also closes a connection leak when running the test suite.