Hanami 2.0 Ideas

#21

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:

#22

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

#23

@CassioGodinho

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.

#24

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

#25

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.

#26

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

#27

To add:

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

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

#29

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.

#30

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

#31

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.

#32

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

#33

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

#34

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.
#35

@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?

#36

@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.

#37

@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?
#38

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.

#39

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:

#40

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.