Hanami 2.0 Ideas


First of all, I’m very happy to hear that Hanami team is considering Webpack. Webpack is an awesome tool to bundle/process assets.

I’ve created the hanami-webpack, a very experimental and hacky gem to run Webpack with Hanami, but it’s important to tell that I just followed some principles that I saw in https://github.com/mipearson/webpack-rails.

The answers to your questions:

In my gem I used the Webpack’s StatsPlugin to expose, through a JSON manifest, the path for my [webpack entry points] (http://webpack.github.io/docs/configuration.html#entry), so the Hanami can download this manifest in order to figure out the paths for the entries.

Here some key points about the implementation:

About the server, I totally agree with you about the smooth integration between webpack dev server and Hanami, in my gem I made a monkey patch on the Hanami::DevServer.start to spawn a process with the webpack dev server https://github.com/samuelsimoes/hanami-webpack/blob/master/lib/hanami_webpack/dev_server.rb#L7 to make the dev server integration transparent, I don’t know if it’s a good idea, just sounded good for me.

I’m not a specialist in Webpack or Hanami, but I’m glad to help you guys on this topic. :smiley:


@samuelsimoes Thanks for joining this conversation. Do you use hanami-webpack in production?



You can mount middleware at action level, or you can share a module across all the actions, so #authenticate! is always called, unless you want to skip it.


I’m using this gem in http://ossboard.org :slight_smile:


Not in this moment, I created the gem for a pet project that still in development. But I use the react-rails (that follow the same principles, like I said) in a production app.


What do you mean by “Expand the capabilities of our helpers”?


To add:

  • remote: true option for AJAX calls for forms and links.
  • disable_with: "Submitting.." for buttons


I think we need to discuss API mode for hanami here too. @jodosha what do you say?


I’m not sure it’s worth the pain… IMHO Hanami should focus on ruby and server side stuff. If ppl want to add some data-disable-text in a small npm package compatible with hanami (to be coupled with the webpack proposition), why not, but it’s (again, IMHO) not hanami’s job.


Do you intend to add default instrumentation to the framework to more easily integrate with services like NewRelic, DataDog etc?


Load env files as Dotenv

ATM, Hanami only load the .env.{{environment}} file, while dotenv loads env from several other places:

  • .env
  • .env.{{environment}} <- we load this one!
  • .env.local
  • .env.{{environment}}.local

This allows developers to overload default environment variables (like db links) in a safe (if there’s a new env variable, you won’t miss it) and simple way (just add them to .gitignore)

Even though only .env.{{environment}}.local seems relevant in this use case, as the dotenv gem is in the Gemfile, I think that we should have load the same files as it does.


@jodosha Probably you’ve already noticed it, but vanilla-ujs gem require railtes and sprockets.


@davydovanton Please start the discussion with actionable ideas. Thank you.


I already asked vanilla-ujs maintainer if we can submit a patch to remove that dependencies, and he agrees.

However there is an issue. That gem has application.js with a Sprockets directive that bundles together all the .js files. If we want to use vanilla-ujs we need to manually bundle them into a file (eg. ujs.js) and then we can require it from the template: <%= javascript 'ujs' %>.

We have two solutions here:

  • To maintain a separated hanami-ujs gem with the sole purpose of bundling vanilla-ujs files and to distribute them
  • We can include them directly in hanami.


@titeiko What I want to overcome here, is to have a streamlined way to perform AJAX requests.

I’m fine to not add vanilla-ujs, but still we need a fast and easy way to enable developers to work with AJAX. NPM/Webpack aren’t simple solutions. What do you suggest?


@mereghost I’m not thinking about external services, just a way to have a visibility of what happens at the framework and at the project level.


@titeiko this is a really good idea :thumbsup:.

Can you please elaborate a bit in terms of actionable tasks for us?

  • What files we would create for new projects?
  • Do we want to add some of them to .gitignore by default? If so, which ones?
  • Is it only for development or for test environment too?


NPM/Webpack can be a simple solution:

cd app/web
brew install yarn # or OS equivalent
npm install -g hanami-webpack
yarn add hanami-ajax-forms
yarn install

An hanami-webpack npm package could be the base to install a webpack environment + a command to preprocess assets (with watch option).

This way, you have a simple way for ppl that don’t want to worry about it, but anyone needing a bit more can customize its pipeline. It can also easily be added in the app generation, and be entirely skipped if the app is an api.


This is basically the same idea as laravel-mix, just a stand alone npm package with a default webpack config.
@jodosha sorry for bringing up laravel stuff again :sweat:


New date helpers

Rails has helpful time and date helpers (like distance_of_time_in_words, distance_of_time_in_words_to_now and Date class).

I think we need to create helpers for working with the date. I start working on it but I’ll be happy to see other ideas and (or) feedback.