Let’s learn and work on Hanami together at RubyConf! 🌸🙌
Me: Tim Riley (that’s me!) will be at the RubyConf community day representing Hanami. I’m one of the core team, and have been helping drive the Hanami 2.x development work over the last 4+ years.
You: All are welcome! Regardless of your experience level, please come along and we’ll can help you learn the Hanami gem ecosystem and even put together your first contributions to the project.
hanami generate component command
A hanami CLI sub-command that generates a plain old Ruby class anywhere within a Hanami project, making sure to include all the module nestings required for the class to live at the given path.
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.
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.
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.
Right now these only support the schema portion of validation contracts, which is much less helpful than the full contract itself. Let's find a way to support the full contract here. This might even mean we can drop the hanami-validations gem and just support dry-validation directly, which would be a nice outcome!
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.
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.
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.
Right now the user experience of the hanami CLI tool 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:
- Return better output when unknown flags are given
- Right now this looks like this, which isn't helpful at all:
ERROR: "hanami generate action" was called with arguments "home.show --skip-tests"
- Right now this looks like this, which isn't helpful at all:
- Provide a comprehensive
helpoutput that shows all commands, not just the top level - Slicker
hanami newoutput — more “wow” factor here, please! - As above, generally look to provide more sparkle to our capabilities for CLI outout
- Allow for third party code extending existing CLI commands to register their own specific options on those commands
- Export autocompletion files for shells (like this? maybe this is also relevant?)
- Update the CLI generators (via the underlying dry-files gem) to support manipulating files using Ruby AST instead of string manipulation. Use syntax_tree for this?
We want a replacement for the better_errors gem, built right into hanami-webconsole. Something that provides a modern look and feel, and allows us to customise the user experience for different exceptions.
We want to better protections to ensure that changes in one Hanami gem do not break thigns in another. Having something in CI that generates a full Hanami app (using whatever gem and its branch of code under development) and then extends/tests it with known baseline functionality would be quite helpful.
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...