Hanami v2.0.0.alpha2 app template feedback

[jodosha]

With Hanami v2.0.0.alpha2 release, we built an application template to share with the Community how an app built with Hanami would look like.

We decided that the goal for v2.0.0.alpha3 will be to finalize the application template code.
That means to cleanup application template code, improve it with features, but also extract parts of it in Hanami gems.

---

This forum topic should be used to share feedback regarding the application template, so we can openly decide which work shall be done for alpha3.

Each decision will result into a Trello ticket, which will be taken from any of us into the development process.

For each implemented ticket (into Hanami gems), we must update the application template to reflect the changes from the framework.

---

Please provide your feedback here.

In order to make feedback process easier, please create a separated comment for each file in the application template that you would see to be changed. Use threads to discuss each feedback.

[jodosha]

config/boot/assets.rb

• must be ported to hanami-assets

[jodosha]

Consider to rename Hanami.application.register_bootable into Hanami.container.register, or Hanami.application.container.register.

Similarly we should expose container resolved keys via Hanami.container.keys.

[jodosha]

config/boot/persistence.rb

• must be ported to hanami

[jodosha]

config/puma.rb

• PORT must be 2300
• Consider to introduce stop block in Dry::System.register_bootable so the informations to tear down a component are local to it:

Hanami.container.register :persistence, namespace: true do |container|
  init { ... }
  start { ... }

  stop do
    rom = container["persistence.rom"]
    rom&.disconnect
  end
end

• Consider to introduce Hanami.reboot (or Hanami.application.reboot) which will loop thru the initialised components and invoke stop and then start. This will make Puma’s before_fork much simpler

before_fork do
  Hanami.reboot
end

[jodosha]

config/settings.rb

• Is it possible to have hashes that are mapped to env vars? Something similar to what config gem does:

LOGGING__LEVEL=debug
LOGGING__STREAM=stdout

Hanami.application.settings do
  setting :logging do
    setting :level, MyApp::Types::String
    setting :stream, MyApp::Types::String
  end
end

To be used like this

module MyApp
  class Application < Hanami::Application
    config.logging = settings.logging
  end
end

[jodosha]

config/application.rb

• We should consider to implement environment block for selectively setup configurations:

module MyApp
  class Application < Hanami::Application
    config.environment(:test) do
      # activate this block only if Hanami.env == :test
      config.logging = { ... }
    end
  end
end

[jodosha]

lib/framework/web/assets.rb

• must be moved to hanami-assets

[jodosha]

lib/hanami/action/csrf_protection.rb

• must be moved to hanami-controller and required internally by hanami.

[jodosha]

lib/hanami/cli/**/*.rb

• must be moved to hanami-cli

[jodosha]

lib/tasks

• we should decide how to declare custom Rake tasks to make them available for the app

[jodosha]

lib/my_app/action.rb

• move require “json” to hanami/action/flash.rb source code in hanami-controller gem
• consider to include Hanami::Action::Cookies only if app configuration (config/application.rb) has cookies setup
• consider to include Hanami::Action::Session only if app configuration (config/application.rb) has sessions setup
• consider to include Hanami::Action::CsrfProtection only if app configuration (config/application.rb) has sessions setup
• these inclusions should be handled by the framework, and not appear in the generated code.

[jodosha]

lib/my_app/entities.rb

• consider to remove manual recursive require of the entities in favour of zeitwerk autoloading

[jodosha]

lib/my_app/functions.rb

• migrate from transproc (deprecated) to dry-transformer

[jodosha]

lib/my_app/operation.rb

• Consider to develop Hanami::Operation in hanami:

require "hanami/operation"

module MyApp
  class Operation < Hanami::Operation
  end
end

[jodosha]

lib/my_app/validation/contract.rb

• Why is this nested?
• Generate i18n configuration for validations

[jodosha]

lib/store/view/context.rb

• consider to develop Hanami::View::ApplicationContext in hanami-view, which will include this default setup:

modue MyApp
  module View
    class Context < Hanami::View::ApplicationContext
    end
  end
end

[jodosha]

Use `dry-transformer` for application functions

[solnic]

@jodosha

config/boot/persistence.rb

• must be ported to hanami

I was thinking about shipping rom (the gem) with built-in system components. So then, in hanami, you’d be able to just do something like this:

# config/boot/persistence.rb
Hanami.application.register_bootable(:persistence, from: :rom) do |container|
  after(:init) do
    container["rom.config"].plugin(:sql, relations: :auto_restrictions)
  end
end

In the most simplistic use-case, this would just work too:

require "hanami"

module Bookshelf
  class Application < Hanami::Application
     # this would result in having container["rom"] registered
     # based on DATABASE_URL setting
    register_bootable(:persistence, from: :rom)
  end
end

I also need to figure out how to pre-configure instrumentation, that’s a bit tricky because notifications object that’s used for instrumentation is provided by hanami.

[solnic]

@jodosha

lib/my_app/entities.rb

• consider to remove manual recursive require of the entities in favour of zeitwerk autoloading

This will go away I’ll be adding support for pre-configured structs directly to rom core. BTW I’m for renaming Entity => Struct and sticking to it. This can be of course configurable, but I would vote for using Struct as the default name because Entity can be confused with stuff from DDD where identity is based on a key value (IIRC).