Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Tim Riley
@timriley
this is not a huge burden and it allows you to keep a really clear and consistent class design
dependencies go into state via #initialize, data goes into #call and just passes through
Kelsey Judson
@kj
Yeah, consistency and clear rules is what I'm after here. I think it's one of those situations where my past experience is telling me to do one thing, and I'm having trouble completely letting it go.
Tim Riley
@timriley
heh
Kelsey Judson
@kj
When you're passing this state to #call, would you ever set instance variables, to avoid passing state all around as args to other methods (I think this feels dirty)?
Tim Riley
@timriley
no, no, never do that
#call does not mutate state in any way
don’t assign or change ivars
Again, passing args explicitly to private methods is fine, and it helps maintain the clear class design principle
Kelsey Judson
@kj
I think this is what keeps drawing me back to passing state in #initialize. Just the convenience of having it all there and available at all times.
Tim Riley
@timriley
As a wise person once said, let it go
:P
Kelsey Judson
@kj
Haha, yeah that's probably true!
Tim Riley
@timriley
If you’re having that many private methods, your class is probably doing too much
Kelsey Judson
@kj
Yeah, I don't tend to have too many, so I'm probably complaining about nothing.
Thanks for all your help, I have a lot of thinking to do ;).
Tim Riley
@timriley
np!
Sean Collins
@cllns
I’m using Dry::Validation.Formin an interactor (a PORO, no gem) in order to avoid accepts_nested_attributes_for. Basically I don’t want to tie the form to the implementation of the associations, so the form is all under the same key (user). Right now I’m using the Dry::Validation.Form, but in order to update the association properly, I’m using Hash#slice to pull out the keys I want for the main object, and for the associated object, separately. Anyone have any better approaches? It seems OK but there’s a little bit of duplicated/redundant logic, with all the key names being listed twice: once in the Form, and then sliceing the validated params.
Orban Botond
@orbanbotond

Hi,

Is there something in the trailblazer ecosystem which extracts the info from the reform’s validation block:

    validation :default do
      required(:first_name).filled(:str?)
      required(:last_name).filled(:str?)
      required(:new_email).filled(:str?, format?: /.+@.*\./)
      required(:password).filled
    end

Into a swagger compatible documentation:

    class << self
      def documentation
        {
          first_name:{required:true, type:"String", desc:"First Name"},
          last_name:{required:true, type:"String", desc:"Last Name"},
          new_email:{required:true, type:"String", desc:"New Email"},
          password:{required:true, type:"String", desc:"Password"}
        }        
      end
    end

So that it can be used in swaggers the params declaration:
params Registration::InvestorForm.documentation

Gustavo Caso
@GustavoCaso
@orbanbotond this is the dry-rb channel I think you will get more luck in the trailblazer channel :smile:
Orban Botond
@orbanbotond
oh… right :D
Thx. @GustavoCaso , sorry for the wrong message.
Gustavo Caso
@GustavoCaso
No need to apologise :smile:
Aaron Barthel
@abrthel
Just another example showing the work going on here is important and valuable to more and more people everyday. From my own experience, writing data intensive apps has been a breeze with the introduction of rom, dry-validation, dry-struct and dry-container.
Piotr Solnica
@solnic
:tada:
Spencer Goh
@dymaxionuk
question on Dry::System::Settings::Configuration the Dry::Struct constructor_type is hardcoded to :strict_with_defaults I'm registering a component with passed in config, however for any missing values, I want the underlying concrete implementation class to decide the actual defaults. However settings { } doens't allow missing keys
Piotr Solnica
@solnic
@dymaxionuk this will be addressed in next dry-system version
Spencer Goh
@dymaxionuk
Dry::System.register_component(  blah ) do
  settings do 
    key :my_param, Types::String.optional
  end

  start do
    register :my_component,  ComponentImpl.new(config.to_h)
  end
end

I'd like ComponentImpl to set master/failsafe defaults

@my_param = config[:my_param] ||   "Some default value"

I that logic doesn't really belong in Dry::System component registration.

aah ok thanks @solnic :smile:

also dry-web-roda I'm not a big fan of fact that it creates such a deep nested namespace for subapps.
apps/subapp/system/masterapp/subapp/my_class.rb

I want my subapps to be easily exportable, and pulled out later, so starting with monolith first, then pulling out apps into micro-services later.
problem is the namespace of the subapps is polluted with the master app that it currently lives in.

I noticed in berg-master subapps you don't nest the subapp inside the berg namespace.

is there any plan to make some configurable namespace option to the thor generator code?
Spencer Goh
@dymaxionuk
btw, just wanted to say I really like your dry-rb gems in general. I met Tim Riley at RedDotRubyConf 2016 and have since tried out your gems and like where they are going. Thanks !
Piotr Solnica
@solnic
@dymaxionuk we'll be making namespacing more flexible in dry-system 1.1
also, I don't recall using umbrella app namespace in sub-apps, we don't do it
Spencer Goh
@dymaxionuk
I just checked.. the umbrella is mandatory, and the web example puts the master umbrella app into the namespace of subapp. however just realised if I give it value '' empty string.. it ollapses out the umbrella from the namespace
but can't just omit the umbrella param as command line validation kicks out the code gen :smile:
Piotr Solnica
@solnic
this surprises me
I consider referring to any umbrella constants from within a sub-app to be a code smell
the whole idea with subapps is that you can always a) move a subapp to a separate project b) turn lib into a shared gem c) have it work standalone OOTB
also, thanks for your kind words
Spencer Goh
@dymaxionuk
also have you ever got rack-unreloader working with dry-web-roda ? I got as far as patching reloader.rb#commit() method which blew up on log statement, but still couldn't get it working . didn't give much time to it yet, but just wondering if you had any reloader working?
I'm constrained by Windows at work, unfortunately, so can't use shotgun or other solutions :worried:

Re: subapp generation

dymaxion-mpb:dev tiger$ dry-web-roda generate sub_app test_subapp --umbrella test
      create  apps/test_subapp/lib/test/test_subapp/view/context.rb
      create  apps/test_subapp/lib/test/test_subapp/view/controller.rb
      create  apps/test_subapp/lib/test/test_subapp/views/welcome.rb
      create  apps/test_subapp/system/test/test_subapp/web.rb
      create  apps/test_subapp/system/test/test_subapp/container.rb
      create  apps/test_subapp/system/test/test_subapp/import.rb
      create  apps/test_subapp/system/boot.rb
      create  apps/test_subapp/web/routes/example.rb
      create  apps/test_subapp/web/templates/layouts/application.html.slim
      create  apps/test_subapp/web/templates/welcome.html.slim

if umbrella was optional that would be fine, as by default the subapp wouldn't be nested under [Test]

Spencer Goh
@dymaxionuk
actually the --umbrella '' hack doesn't work ! it messed up the codegen , with blank module names :)
anyway I'll await the next dry-system update with eager anticipation!
thanks
Andy Holland
@AMHOL
@dymaxionuk the idea with that is that everything is name-spaced under your organisation name, to prevent clashes, for example if you have a sub-app called Reporting it would define that as a top-level constant, I don't think that's a good practice personally, but I guess having the flexibility to do so isn't bad either
Tim Riley
@timriley
@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...