These are chat archives for dry-rb/chat

23rd
Aug 2016
Piotr Solnica
@solnic
Aug 23 2016 10:19
@blelump sorry mate, been busy with other stuff, I’ll deal with that namespace nonsense now ;)
Piotr Solnica
@solnic
Aug 23 2016 10:27

I think the problem occurs because in my setup run_tasks_blocks fires before instance

@blelump so, why does it happen?

I think this should be reported as a bug in rails
since run_tasks_blocks has a nasty side-effect they should make sure all railtie instances are created first
Michał Pietrus
@blelump
Aug 23 2016 10:35
@solnic , Hi, re this rake issue, well it's diffcult to say what exactly causes the underlying problem, because now it works for me, even without changing anything :smile:
Piotr Solnica
@solnic
Aug 23 2016 10:41
@blelump I pushed 0.0.2 with your fix nevertheless
Michał Pietrus
@blelump
Aug 23 2016 10:42
sure, thanks !
Piotr Solnica
@solnic
Aug 23 2016 10:42
want a commit bit there in case of other emergencies? :)
I’m NOT using this yet so it’s gonna be low on my list until I start using it
I mostly built it as an excercise to see if it can work with Rails Just Like That™
(and it did)
Michał Pietrus
@blelump
Aug 23 2016 10:44
yep , I am sure you're not :smile: and I am not sure whether I need it either
I've experimented with dry-component earlier before it became dry-system and it worked fine within Rails ecosystem
and now just switched to dry-system
Piotr Solnica
@solnic
Aug 23 2016 10:53
you don’t need it, nobody needs it, but you may want to benefit from it that’s all :)
if you like DI, if you don’t like spring, if slow boot time bothers you, if you like well organized code etc…then you will benefit from it :)
Michał Pietrus
@blelump
Aug 23 2016 11:41
@solnic , I'm not sure I follow you, but I meant the dry-system-rails lib. If you inject IoC into an existing app, you may want to not load everything by default and hence the dry-s-rails is not needed. That's what I'm doing now – in particular to check whether there're benefits of this approach . Speaking about benefits :smile: , have you applied the component approach in a bigger app? I'd like to ask about the concept of splitting app into smaller components or what could be a component. I know icelab::berg implements two components and there're probably various ways of doing it , but just wanted to ask about your point of view :-)
RKushnir
@RKushnir
Aug 23 2016 12:30
in dry-v, if I just declare an attribute as required(required(:name)), it seems to have no effect until I chain some rules on it(required(:name).filled), is it right?
Piotr Solnica
@solnic
Aug 23 2016 12:36
@RKushnir right, that’s sth to improve
RKushnir
@RKushnir
Aug 23 2016 12:37
@solnic thanks, not that I need it now, just verifying my understanding
Piotr Solnica
@solnic
Aug 23 2016 12:40
@RKushnir if you enable explicit type-specs then it’ll coerce based on required(:foo, :str)
so ie { “foo” => “haha” } would be processed into { foo: “haha” }
RKushnir
@RKushnir
Aug 23 2016 12:42
I see. But there’s no way to specify “key is required with any value”
Piotr Solnica
@solnic
Aug 23 2016 12:43
@fran-worley hey…so I made most specs pass with way less objects allocations, for invalid-input cases prev perf was restored, this is good news, but there are bad news too - this approach makes it impossible to skip results for successful rules, since we curry prior applying, so it’s a chicken-egg situation - we need result in order to know if we want to generate more result data, but now we already generate more result data before getting the result. haha such situation
@RKushnir nope, why would you need that?
@fran-worley when working on this I had this feeling that this could be much better structured, so I’ll continue experimenting, I feel like something is clearly missing at the moment
RKushnir
@RKushnir
Aug 23 2016 12:47
@solnic I was thinking about a case where I want a caller to always explicitly provide a value, even if it’s an empty string, for example. But as I said, that’s just speculations, never mind
Piotr Solnica
@solnic
Aug 23 2016 12:48
@RKushnir I’m trying to understand if there are legitimate cases where “any type” makes sense
@fran-worley anyhow, my plan is to pretty much rewrite dry-logic lol, I’m pretty sure current class structure is a blocker for what we want to achieve. Good news is, as long as it produces expected ast dry-v will continue to work
Fran Worley
@fran-worley
Aug 23 2016 12:52
@solnic Makes sense. Do we have any independent users of dry-logic yet? I've not yet finished our implementation with it so go nuts :) If you want help and explain where you need it I'm happy to assist. At the same time I don't want to hold you back if you know where you want to go with it!
Piotr Solnica
@solnic
Aug 23 2016 12:54
@fran-worley I don’t think that anybody is using it directly, and even if it’s the case, it is beta, so things can change :P
anyhow, I’ve got a rough idea how to make it work, ie rule/predicate should behave exactly the same wrt #call and #curry there should be no diff and it should be done in a single place
furthermore, we need two different execution strategies, one that generates full result data by currying all args + calling, and the other that simply calls and returns true or false for each rule
Fran Worley
@fran-worley
Aug 23 2016 13:22
Oh I know we can change things, I just figured if we know that someone is actively using it we should probably warn them that it's going to change alot.
Just incase you are wondering why I don't actually curry the predicate function, rather I keep track of the args that was because if you curry a function it is no longer able to determine arity and parameter names which are key to getting arg names into the ast
Piotr Solnica
@solnic
Aug 23 2016 13:23
@fran-worley thanks, you left a comment explaining it :)
Fran Worley
@fran-worley
Aug 23 2016 13:24
I know, I wasn't sure if it was still there been so long now!
Piotr Solnica
@solnic
Aug 23 2016 13:24
it’s there
fwiw I think we can remove Predicate class
and just have rules
the hierarchy is a bit awkward right now
Pau Ramon Revilla
@masylum
Aug 23 2016 15:54
hi there!
I was trying to use dry-validation in a rails project and I'm stumbling upon this error:
Dry::Container::Error:
There is already an item registered with the key "type?"
I've seen in other dry repos this may be related to rails code loading
does it sound familiar?
Piotr Solnica
@solnic
Aug 23 2016 15:59
@masylum install dry-types-rails that should help
Pau Ramon Revilla
@masylum
Aug 23 2016 16:03
trying...
Pau Ramon Revilla
@masylum
Aug 23 2016 16:22
didn't work
the problem is the require 'dry-validation' line
if I remove it, it does not find the Dry module
Piotr Solnica
@solnic
Aug 23 2016 16:26
for now you can just move stuff that uses dry-v/t to a dir that is eager-loaded so that rails doesn’t try to reload the constants
typically lib should be OK (IIRC)
Robin Bühler
@openscript
Aug 23 2016 16:45
Hi all! :-) Are there no setters for a type, because a the concept of a type doesn't foresee setters?
Nikita Shilnikov
@flash-gordon
Aug 23 2016 16:48
@openscript we strongly encourage people not to use mutation
Robin Bühler
@openscript
Aug 23 2016 16:51
Thank you for the article. I'll read through it :-)
Nikita Shilnikov
@flash-gordon
Aug 23 2016 16:55
it usually takes a while to become handy with these techniques, but it's worth it
Daniel Vandersluis
@dvandersluis
Aug 23 2016 18:02
Is there a way to set dry-validation configuration globally, I'd rather not have to do this in each schema:
configure do
  config.messages_file = Rails.root.join("config/locales/errors/#{I18n.locale}.yml")
  config.messages = :i18n
end
Piotr Solnica
@solnic
Aug 23 2016 18:10
@dvandersluis http://dry-rb.org/gems/dry-validation/basics/working-with-schemas/ scroll to “Defining Base Schema”
Daniel Vandersluis
@dvandersluis
Aug 23 2016 18:10
aha! I looked through the documentation a bunch of times but must have missed that, thanks!
any idea if it works with Reform?
Piotr Solnica
@solnic
Aug 23 2016 18:11
@fran-worley ^^^ ????
Michał Pietrus
@blelump
Aug 23 2016 18:11
@dvandersluis sure, it does
Daniel Vandersluis
@dvandersluis
Aug 23 2016 18:14
excellent, thanks guys!
Fran Worley
@fran-worley
Aug 23 2016 18:15
@solnic sorry. Aside from the new applied concept, predicates just seem to do different things. However that is probably just because I'm not inside looking at it from the same angle you are.
Michał Pietrus
@blelump
Aug 23 2016 18:16
@solnic , any idea how to deal with hot reloading within container ? It seems it introduces a lot of unexpected behavior while reloading constants with Rails on board . Besides I've noticed strange things, where probably random constants aren't loaded, despite its siblings from the same dir are present
hi @fran-worley
Piotr Solnica
@solnic
Aug 23 2016 18:16
@blelump it is not working with hot-reloading
we need some kind of integration for that
as it’s usually the case :P
Michał Pietrus
@blelump
Aug 23 2016 18:17
yep :-) , do you have any idea for that?
or it needs further exploration
Piotr Solnica
@solnic
Aug 23 2016 18:18
no, no ideas, not yet at least
Michał Pietrus
@blelump
Aug 23 2016 18:18
sure
Piotr Solnica
@solnic
Aug 23 2016 18:18
it was easy in rom though, just override container with a new instance, but rom has a local container object, in dry-system we’re talking about global classes, this makes it harder
I mean internally there’s just an object storage
so we can add an interface for clearing it
it’s Dry::System::Container._container
reseting it would probably do the trick
as the system would load components again
Michał Pietrus
@blelump
Aug 23 2016 18:20
OK, thanks for the tip, I'll try to experiment with it tomorrow
Fran Worley
@fran-worley
Aug 23 2016 18:25
Hey @blelump how's things?
Michał Pietrus
@blelump
Aug 23 2016 18:44
@fran-worley , all good, you ?
@solnic , it seems before I'll get into container reloading, there's an issue with constants reloading that are loaded into container as well. During dev mode, once I make any change in any file, it ends up with superclass mismatch for class ... and so far the only solution I have is to remove_const, but that's a pain
Andy Holland
@AMHOL
Aug 23 2016 19:02
Guess that's for inheriting from things like ROM::Relation[:users] etc?
Was thinking recently since we don't mutate, might be a good idea to cache those
Although I guess removing the constant makes sense when reloading
Piotr Solnica
@solnic
Aug 23 2016 19:05
it’s because it removed the constant but the container had a reference to the prev one BECAUSE CODE RELOADING IN RUBY IS NOT WORKING
Andy Holland
@AMHOL
Aug 23 2016 19:05
Still a problem with nested classes tho
Ahh OK
Piotr Solnica
@solnic
Aug 23 2016 19:06
irb(main):001:0> Foo = "HAHA"
=> "HAHA"
irb(main):002:0> Bar = Foo
=> "HAHA"
irb(main):003:0> Object.send(:remove_const, :Foo)
=> "HAHA"
irb(main):004:0> Foo
NameError: uninitialized constant Foo
    from (irb):4
    from /Users/solnic/.rubies/ruby-2.3.1/bin/irb:11:in `<main>'
irb(main):005:0> Bar
=> “HAHA"
that’s probably one of the many cases where things can go wrong
Michał Pietrus
@blelump
Aug 23 2016 19:08
@solnic , uhm, thanks for explanation
Piotr Solnica
@solnic
Aug 23 2016 19:09
we’ve been talking about a stable way of reloading via container
I think it should be doable with no surprises
since the only thing we need to be concerned with is stuff inside the container, rather than THE WHOLE runtime env
Piotr Solnica
@solnic
Aug 23 2016 19:16
@blelump re your question from earlier today, I used similar approach last year in a biggerish rails app, started with dry-container, then auto_inject was born from it, then I built rodakase, then dry-component was born from it, then we built a couple of dry-web (post-rodakase) apps with Tim at IceLab, they are a couple times bigger than Berg, all use multi-system setups. 95% of the features we have in dry-system/container/auto_inject are a result of discovering specific needs when working on these apps. Overall we’ve been super happy with how it works; however, we are hitting some challenges, ie in dev mode shotgun is too slow and makes clicking through the website too slow, we’ll be addressing this shortly (that’s related to code reloading, although I don’t know what strategy we will use eventually)
Daniel Vandersluis
@dvandersluis
Aug 23 2016 19:42

I'm probably missing something obvious, but i'm getting behaviour that seems wrong to me. Consider the following

configure do
  def valid_email?(value)
    true
  end
end

required(:email).filled(:valid_email?)

When I pass in a blank string for email, I always get BOTH error messages (:email=>["must be filled", "Email is invalid"]). If blank I just want the "must be filled" error.

required(:email) { filled? & valid_email? } gives me the same
Also as you can see, the valid_email? predicate always returns true and yet still adds an error
Piotr Solnica
@solnic
Aug 23 2016 19:58
@dvandersluis that’s a hint, not an error, we’re gonna make that configurable (opt-in/out) and you can override it’s message via en.errors.valid_email?.(hint|failure)
so ie you can put under hint sth like make sure it’s a valid email
and for failure “this does not look like a valid email”
Daniel Vandersluis
@dvandersluis
Aug 23 2016 20:00
ah okay that makes sense
so as of 0.9.5 there's nothing I can configure right?
Piotr Solnica
@solnic
Aug 23 2016 20:01
@dvandersluis you can do schema.(input).message_set.dump to skip hints
it’s gonna return a hash with failures exclusively
default behavior of #messages is to include them
btw more insights about hints/failures here dry-rb/dry-validation#225
Daniel Vandersluis
@dvandersluis
Aug 23 2016 20:02
ok I'll check that out.
I'm using dry-v via reform so I'm not sure how I would go about calling the message set, but I'll see what I can figure out
Piotr Solnica
@solnic
Aug 23 2016 20:03
@fran-worley ^^^ ??? (again :D)
Daniel Vandersluis
@dvandersluis
Aug 23 2016 20:03
:)
Fran Worley
@fran-worley
Aug 23 2016 20:24
@blelump good thanks. Just doing the docs for Formular which should help you and is pretty much the last thing before release!
@solnic I was just wondering how your going to merge them. Though the more I think about it the more it makes sense. Funny how long it takes to see something clearly!
Michał Pietrus
@blelump
Aug 23 2016 20:33
@fran-worley :fireworks: :sparkles:
Piotr Solnica
@solnic
Aug 23 2016 20:34
@fran-worley the class hierarchy is a bit borked, ie Predicate is not the most low-level primitive “rule” type, as it has an identifier, which is a very specific concept in dry-logic - a named rule, so ie Rule::Key is a named rule and…Predicate is a named rule too
so basically we can’t treat predicate objects as some low-level rules
furthermore, the issue with 2 types of return values is troublesome, this must behave in a consistent manner since a rule have a predicate, and that predicate can be another rule OR a predicate itself, this made things more complex than it should be
so essentially we need a single rule concept, with various specialisations, and predicates should be just…methods returning true/false (so ie anonymous blocks or methods from modules/classes/objects that we detach via Method objects)
this should simplify the whole thing, as we’re gonna deal with just one concept - rule
and I’d like to try to keep the idea of “an applied rule” where all args are filled, we’ll see how it goes
the requirement is that rule instantiation must not be too expensive
Piotr Solnica
@solnic
Aug 23 2016 20:43
@flash-gordon I was typing a response to that new dry-types issue and SUDDENLY your reply appeared, I freaked out, I freaked out badly :laughing:
Nikita Shilnikov
@flash-gordon
Aug 23 2016 20:45
@solnic ah, just the only question I know the answer to :laughing:
Fran Worley
@fran-worley
Aug 23 2016 20:49
@solnic makes sense it always seemed kinda irritating that really simple rules with essentially just one predicate had to get wrapped in a rule object. Do you mind if I capture your thoughts above and add them as a comment on the dry-logic PR ?
Michał Pietrus
@blelump
Aug 23 2016 21:01
@solnic , thanks for detailed explanation ! Re the container issue, it seems _container comes from dry::container, however when finalize! is performed, it also freezes the system::container itself. I am out of ideas for today , see you tomorrow :-)
Piotr Solnica
@solnic
Aug 23 2016 21:05
@blelump oh we just would not finalize! in dev mode, that’s all