Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Rafael George
@cored
'when you do this you will have that' because even following the integration specs is hard to know how everything works together from a client point of view
Piotr Solnica
@solnic
@cored the intentation of these specs wasn’t really to document usage :)
Rafael George
@cored
do you think will be valuable to have somthing like that ?
Piotr Solnica
@solnic
not sure tbh, the amount of use cases that we have is enormous, pretty much unlimited, there are already thousands of integration specs, not sure what kind of value feature specs would give us
esp that at the end of the day we need to write user documentation anyway
no specs will replace that
so I’m not very fond of the idea of having even more specs, unless they really provide additional value from test cov pov
Rafael George
@cored
gotcha
I was trying to understand what will be an entry point for the library
Jānis Miezītis
@janjiss
This message was deleted
Jānis Miezītis
@janjiss

Hey folks, wanted to discuss following idea. In application there are cases
where I want to have inheritance on Dry::Struct, but the child struct has
few less attributes. For example user has name, but manager does not require it:

class User < Dry::Types::Struct
  attribute :name, Dry::Types::String
end
class Manager < User
  ignore_attributes :name
end

What about having ignore_attributes option that just removes a specified attribute? Thoughts?

Piotr Solnica
@solnic
@janjiss just restructure your inheritance hierarchy so it’s not needed
@cored an entry point?
Rafael George
@cored
like I think in terms of what operations can I do with this system
Piotr Solnica
@solnic
Schema#call
Rafael George
@cored
taking an example from your own talk
you had something like CreateUser def call() method in that case createUser is my entry point
maybe a vague word to describe that situation
John Backus
@backus
@backus do you think we could wrap up dry-struct?
I have a growing need for it in my current project at work…I start having usecases similar to yours, so I’m motivated to help with that
@solnic I'm glad our use cases are beginning to overlap :) :)
I can try to find some time for it soon
To manage expectations though you should know that I have some big deadlines for work over the next 7 days so I might not get to it until then worst case
Piotr Solnica
@solnic
@backus cool man, it’d be awesome if we could wrap this up before Sept 12
John Backus
@backus
Okie doke that works with my timeline I think
Piotr Solnica
@solnic
@backus I fixed a bunch of things today so it’s pretty much ready for development
John Backus
@backus
Nice yeah I saw
I assume the constrained? thing is API on dry-types that needs to be consistent
Piotr Solnica
@solnic
@backus that and also fixed gemspec to use VERSION and fixed one failing spec due to a reference to a constant that was no longer there :)
small stuff
John Backus
@backus
Great
@solnic do you think dry-struct needs to implement these new interfaces before it can be released?
in other words, are the different constructor behaviors release blockers?
Piotr Solnica
@solnic
no, but I wouldn’t want to release it w/o them, as it’s gonna introduce a new lib, so people may start picking it up, and a couple of weeks later we may change things, so better to change it already :)
John Backus
@backus
ah kk
Jānis Miezītis
@janjiss
Is there a way to map Sequel result set to Dry::Structs apart from doing result.map {|attrs| MyStruct.call(attrs) } ?
Don Morrison
@elskwid
Hey @blelump, did you ever get your reloading thing working? The message I saw you post seemed familiar to me - something we saw when using Wisper in Rails.
The fix was to wrap up the container clearing in the Rails.application.config.to_prepare block. Not sure if that will help you but it may.
Krzysztof Wawer
@wafcio
@solnic What is the difference between load_path and auto_register ? In example code (dry-system) you use these two methods with the same arguments. I read dry/system/container.rb but unfortunatelly I still don’t know the difference
Tim Riley
@timriley
Load path just adds the directories to Ruby's $LOAD_PATH
Krzysztof Wawer
@wafcio
I have just found small bug in dry-system, comment say that system_dir by default is component but in code I see system value. I can send PR with fix it but I don’t know which part should be changed
Michał Pietrus
@blelump
Hi @elskwid ! Nah, not yet... From what I remember, the Rails.application.config.to_prepare performs after reloading so I've started with ActionDispatch::Reloader.to_prepare. However, even though I explicitly override the container instance (AppContainer.instance_variable_set('@_container', ::Concurrent::Hash.new)), the underlying problem still persists. I've seen how dry-t rails solves this problem, but I'm not sure it would help. I'll start with it again in September
Andrew Kozin
@nepalez

@keeperhood
I think, the error you've reported yesterday, caused not by super method (it should work), but unexpected data you send to the initializer.

This definition

class IsobusExportAdapter
  extend Dry::Initializer::Mixin

  option :application_map_id
  option :field_id
  option :strategy_bundle_id
  option :worker
end

is equal to

def initializer(application_map_id:, field_id:, strategy_bundle_id:, worker:)

Notice, that this method expects hash with symbolic keys, not strings. If you try to send something like this

{ "application_map_id" => 1, ... }

Then you'll receive exactly the same error you've reported:

ArgumentError: wrong number of arguments (1 for 0)

So the solution of your problem would be like this (if you want to send hash with indifferent access to the initializer):

class IsobusExportAdapter
  # ...
  private

  def initialize(hash)
    # symbolize keys of the input hash
    super(hash.each_with_object({}) { |(key, val), obj| obj[key.to_sym] = val })
  end
end
(OMG, I wonder whether I like this parrot style of snippets)
Tim Riley
@timriley
@wafcio the right name should be "system" - thanks!
Sergey Kukunin
@Kukunin
is there a way in dry-v to set empty value for key in output array, even there was no key in input hash. Like
MySchema = Dry::Validation.Form do
  optional(:key).maybe(:str?)
end
validation = MySchema.call({})
validation.output[:key] == nil
Piotr Solnica
@solnic
@Kukunin nope, schema doesn’t fill in missing data
Jānis Miezītis
@janjiss
Guys, in my schema I have - required(:email).filled({format?: EMAIL_RGEXP}, :email_unique?)
Where :email_unique? is a call to DB. The problem that I have is that if first validation fails, there are two error messages appearing even if the email is not already taken. Same stuff happens if I do it vice versa. Both for format and email uniquiness:
:email => ["Email is in invalid format", "Email is already taken"]
Adam Davies
@adz
@janjiss I just started with dry-validation and had similar thing happen (cc @yujiyokoo ). I’d like to understand what should happen… but we got around it by adding a second rule:
rule(email: [:email]) do |email|
  email.format? & email.email_unique?
end
and first one just had required(:email).filled(:str?)
Jānis Miezītis
@janjiss
@adz Thank you for the reply!