Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Fran Worley
@fran-worley
@georgemillo Sounds really cool, might do a minitest equivalent and actually use it in Reform :)
George Millo
@georgemillo
I opened at issue over at Reform if anyone wants to weigh in on this further: trailblazer/reform#414
Hannes Nevalainen
@kwando
hmm, is there a way to check that error messages have been defined for all predicates? would be nice to just tell "something" to check if I have provided error messages for all custom predicates (don't like to blow up on Dry::Validation::MissingMessageError)
This doc has a link to a gem called dry-component but the link is dead
has this gem been renamed?
oh wait, Google suggests that this is the old name for dry-system
amirite?
Nikita Shilnikov
@flash-gordon
yep
Andrew Thauer
@andrewthauer

Question - I’m looking at using dry-rb to build a re-usable gem that allows the consuming application to define & configure the persistenance layer, and other infrastructure related dependencies. I’ve got this more or less working when I explictly ask the container to resolve the dependency just before I need the service.

class SaveMyEntity
  def call(entity)
    my_repo = MyContainer[‘persistence.my_repo’]
    my_repo.save(entity)
  end
end

I’m wondering if I can also use either dry-auto_inject and/or dry-system to also do this? However, from what I can see, using the auto loading and the auto injector work differently.

Import = Dry::AutoInject(MyContainer)
class SaveMyEntity
  include Import[‘persistence.my_repo’] # throws Dry::System::ComponentLoadError: could not load component
end
Tim Riley
@timriley
@andrewthauer That should work. How are you setting up that “my_repo” registration?
Andrew Thauer
@andrewthauer
Sorry, I realized that using Application.inject vs Dry::AutoInject seem to behave differently. My mistake, the above example does work, but the Application.injector (suggested by the dry-system example), throws the above exception.
Does one lazy load dependencies and the other does not?
Tim Riley
@timriley
Dry::System.injector will give you an injector that lazy loads for containers that aren’t finalized, yes
But it’ll only lazy load according to certain strategies (though we’re actively improving that), so if your “persistence.my_repo” registration falls outside of that, it’ll not work
Andrew Thauer
@andrewthauer
Import = Dry::AutoInject(Container) # works
Import = Container.injector #  throws Dry::System::ComponentLoadError: could not load component

I’m currently calling one of those 2 lines inside a module pretty much when the gem is initially loaded. The first line seems to work, but the 2nd throws the error when I use the Import in a subsequent ruby file. Should I be deferrring these until after the consuming application has a chance to register it’s own dependencies?

Basically, just trying to figure out the correct pattern to use moving forward. I’m not sure, if I should be bothering with dry-system in my case or just leverage dry-container and possibly dry-auto_inject.

Tim Riley
@timriley
You’re probably seeing an error with dry-system’s injector because it’s trying to do the lazy load as soon as it is included into a class
whereas plain auto-inject doesn’t do any lazy loading at all
which is why it doesn’t bother to resolve the deps until you actually initialize that class
in dry-system master branch we’ve actually changed lazy loading so it does it upon class initialization too, not at include-time anymore
so that might be worth trying
but yeah, in general with dry-system for a non-finalized container, if the lazy loading fails, you’ll get an error
for a finalized container, your deps should all be registered anyway, since the container is frozen at that point
Andrew Thauer
@andrewthauer
I don’t recall actually using the finalize! method (although I did see it). Is this required or not? I don’t have any issues having the consumer of the gem have to explicitly call something to finalize and freeze the dependencies. Just need to make sure things get loaded correctly without a wierd order of operation issues. Is there particular pattern you would suggest to allow for a consumer to configure dependencies?
Tim Riley
@timriley
So you’re expecting the consumer to supply their own container?
Andrew Thauer
@andrewthauer
Or configure pieces of the main gem’s application container. It’s kindof two old. The initial usage of this new domain model will be integrated into 1 system which I’d like to leverage the existing persistence there. However, in the future the same domain logic could be useful in other applications. Further thinking down the road, it might make senes to extract out persistence to a shared application in an SOA environment. I figure putting the architectural boundaries now should afford making this refactoring much easier down the road (i.e. swapping out a repository from a database call to a web service call).
Tim Riley
@timriley
right, OK. So if you’re providing a container and it’s a Dry::System::Container, then I’d expect a boot sequence for the container to be something like this when running in a production-like environment:
# Require the container
require_relative "main/container"

# Load files with manually registered dependencies
Main::Container.require "component/container/persistence"

# Finalize the container, which does auto-registration if you've configured it
Main::Container.finalize!
That way your container reaches a reliable state right up front and is frozen from there
the lazy loading feature of non-finalized dry-system containers is really meant for isolated unit testing, where you want it to be fast, so you load up an empty container (don’t finalize) and then rely on the lazy loading to get just the right combination of components you need for your unit test to run
Tim Riley
@timriley
If you don’t want to require your consumers to undergo a “boot” process like this, then maybe dry-system is not what you want. (But then you’d do without features like auto-registration etc., but I’m not sure how important they are for you in this thing you’re building)
Andrew Thauer
@andrewthauer
I think, I’d be fine having the consumer go through a boot process. The initial consumer will be a rails application. So my initial thought is to have config/initializer that does the boot process your suggesting (where the middle line loading the rails defined repositories, etc.). I’ll have to try out a couple things to see what works. Thanks for you help!
George Millo
@georgemillo
is there any documentation for dry-view?
Valentin Trinqué
@ValentinTrinque

Hi guys, I have some trouble using dry-validation. I am trying to ensure that some ids I receive from my API are actually valid records in my database. In my form I have this :

property sender_ids
required(:sender_ids) do
  filled? & array?
end
rule(valid_senders: [:sender_ids]) do |sender_ids|
   Contact.exists?(id: value(:sender_ids))
end

But it raises the following error :

POST /letters with valid data returns the new letter
Failure/Error:
  rule(valid_senders: [:sender_ids]) do |sender_ids|
    Contact.exists?(id: value(:sender_ids))
  end

NoMethodError: undefined method `with' for false:FalseClass
# ./.gems/gems/dry-validation-0.10.4/lib/dry/validation/schema/value.rb:96:in `rule'
# ./app/forms/letter/create_form.rb:31:in `block in <class:CreateForm>’

Do you have any idea ?

Valentin Trinqué
@ValentinTrinque
I fixed the problem by creating a valid_contacts? function inside configure hook and call it from the required statement
Tim Riley
@timriley
@georgemillo unfortunately no docs right now, we’re still figuring dry-view out a little bit. I hope to spend some of January on it and hopefully doc some things up then too.
Christopher Dennl-Ortega Arrieta
@cdennl
@ValentinTrinque for arbitrary boolean checks you dont want to use rule but validate, see dry-v docs
rule just works on predicates
Andriy Tyurnikov
@andriytyurnikov
Hello. @timriley do you have some plans about dry-web-roda || icelab/dry-web-skeleton ?
Andriy Tyurnikov
@andriytyurnikov
Basicaly it would be nice to know if you guys fundamentally opposed to idea of adding foreman and dotenv to the dry-web-roda default stack
Ilya Bylich
@iliabylich
Hi there. Currently I'm trying to replace AM::Validations with dry-validations but I can't generate correct error message. Let's say I have a scheme with attribute
optional(:attribute_name) { eql?('') | none? | (str? & format?(/\w+/) & max_size?(10)) }
By calling
MyScheme.call(attribute_name: 'some invalid value').messages
I'm getting errors as a single string
{:attribute_name=>["must be equal to or must be a string or is in invalid format or size cannot be greater than 10"]}
I need to have one error message for all kind of errors, like "Attribute name must contain < 10 symbols from the following list: ..."
Is it possible?
After a quick look at Dry::Validation::MessageCompiler I guess it doesn't support any options for switching generating strategies...
Christopher Dennl-Ortega Arrieta
@cdennl
@iliabylich write a custom predicate/rule and make a message for it
Ilya Bylich
@iliabylich
This is the default behavior in my system (which means that I have to write custom predicate for each attribute)
I've tried to read the source code of dry-validation and it seems that | (Or) is the only node in produced AST that gets converted to a non-array value
By using &, > or ^ my errors messages are not joined. This code is a problem for me - https://github.com/dry-rb/dry-validation/blob/master/lib/dry/validation/message.rb#L35 - and I have no idea how to solve it without patching
Christopher Dennl-Ortega Arrieta
@cdennl
@iliabylich no you write ONE predicate which does aggregates all the single validations and call this one, and this predicate you can give a custom message
def my_predicate
  return eql? || none? || ... #this is pseudo code
end

my_predicate: 'custom message'

optional(:attr) { my_predicate }
Tim Riley
@timriley
@andriytyurnikov dry-web already has some sort of application config system, but I’m interested in making it behave a little more like dotenv instead of using a .yml file. As for foreman, this seems like something that’s better suited to people’s own skeletons or applications rather than being built in?
Pol Miro
@polmiro

hi! I'm running into a struggle with dry-transaction and I wonder if it is something any of you have run into.

1)The interface expected is always in the form call(input) but since we have been using dry-initializer a lot, our callable objects are initialized with the input, and called with call() without any arguments.
I can wrap the registered methods so they get called correctly but seems a bit of an overhead. Step adapters don't really solve anything since they adapt the handling of the output but not the way the method is called.
Is there any way to streamline this? Has any of you felt this need before?