These are chat archives for dry-rb/chat

31st
Jan 2018
Tim Riley
@timriley
Jan 31 2018 09:09
@dymaxionuk hey hey! (I just wrote back to your email btw) — thanks for bringing this stuff up. It’s actually a change we made recently to the application generators to keep everything under the single application namespace, just like @AMHOL described.
There were a couple of reasons I had for it:
  1. Prevents namespace pollution. In the same way in the dry-rb org we try to keep everything under module Dry only, your app does the same thing with its own top-level module.
  2. It actually helps to make constant resolution nicer when you’re sharing code between sub-apps by putting them in the top-level namespace. Example to follow...
If my app is Blog and my sub-app is Blog::Admin, then in apps/admin/lib/blog/admin/whatever.rb I can more easily e.g. inherit from Blog::Something by:
require “blog/something”

module Blog
  module Admin
    class Whatever < Something # doesn’t reqiure explicit Blog::Something naming because we’re already in that namespace
    end
  end
end
That’s just a small nicety but we’d actually seen it enough in our apps that it made sense to me to make it so the sub-apps could be situated “within” the larger overall app namespace, instead of being situated “alongside” it.
There’s nothing in this arrangement that would stop the various components/sub-apps to be teased apart into different codebases or distinct services
Tim Riley
@timriley
Jan 31 2018 09:15
you’d still name them by their relationship to the larger whole, e.g. blog, blog-admin, blog-<whatever>
I can see how it may not suit everyone’s exact requirements though, so I think when I get to improving the dry-web CLI and code generators, I’ll make this more easily configurable
I did some work on this last year and I hope I’ll be able to get back onto it sometime next month
Spencer Goh
@dymaxionuk
Jan 31 2018 11:22

Thanks for the reply TIm. Just one other thing I noticed (and maybe I'm missing some default cfg somewhere) but the routing seems to work differently vs default Roda routes.

r.get "ping" do
  'pong'
end

with App < Roda this matches only <url>/ping
whereas with App < Dry::Web::Roda::Application this appears to match <url>/ping/*

Is this intentional or did I miss something silly?

Piotr Solnica
@solnic
Jan 31 2018 11:25
@dymaxionuk this doesn't look right, there are some extra plugins enabled, so MAYBE one of them is causing this (but I don't think so)
Spencer Goh
@dymaxionuk
Jan 31 2018 11:28

@solnic weird, cos I just typed up this config.ru file

# cat config.ru
require 'roda'
require 'dry/web/roda/application'

class App < Dry::Web::Roda::Application # Roda
  plugin :json

  route do |r|
    r.get 'ping' do
      'pong'
    end
  end
end

run App.freeze.app

and verified the behaviour on both my windows & osx box

oops ignore the :json naturally
Piotr Solnica
@solnic
Jan 31 2018 11:35
see which plugins are enabled
as I said, maybe it's because of the plugins
Spencer Goh
@dymaxionuk
Jan 31 2018 11:38
yes it's plugin :flow which is in Roda::Application causing it..
flow is supposed to just provide the resolution of IOC container objects, but seems to have this side-effect... suprised noone else is affected? do you work around this somehow with your routing?
Spencer Goh
@dymaxionuk
Jan 31 2018 11:51
also curious.... I like the dry-rb extensive use of module builder pattern eg. Dry::Equalizer( ... ) and App::Import[ ... ] however there seems to be some inconsistency, sometimes () vs [] - do you have any convention for when you define as () vs [] ?
Nikita Shilnikov
@flash-gordon
Jan 31 2018 11:56
Import is a global object and Equalizer is a global function, objects are stateful, functions are stateless hence the difference
Spencer Goh
@dymaxionuk
Jan 31 2018 11:57
:thumbsup: :smile:
Piotr Solnica
@solnic
Jan 31 2018 12:53
@dymaxionuk ie there's def Equalizer inside Dry namespace, so you can do both Dry.Equalizer() or Dry::Equalizer()
Spencer Goh
@dymaxionuk
Jan 31 2018 13:07
If I want to have a injected component X which is used in multiple subapps . eg. but have differently configured instances of X in each subapp's container.
Dry::System::register_component (http://dry-rb.org/gems/dry-system/component-providers/
I don't necessarily need it in a separate gem or to externalise this - so what's the best way to do this? I've got it working like this now , but is there a simpler way?
thanks
Piotr Solnica
@solnic
Jan 31 2018 15:20
@dymaxionuk just register it within your app somewhere