These are chat archives for dry-rb/chat

9th
Jun 2016
Ralf Schmitz Bongiolo
@mrbongiolo
Jun 09 2016 02:59
@solnic thanks for the tip, I'll see if I can use something like this on my current setup
Tim Riley
@timriley
Jun 09 2016 04:44
Started sketching out a dry-skeleton CLI for generating apps of any kind via skeleton gems. The idea would be that you run dry-skeleton generate skeleton_name <other options here> and it finds an appropriate gem/github repo to do the work. This is just so we can have a unified entry point for generating dry-web apps. I’m planning to make it so the dry-skeleton gem then offers some convenient code generation classes (via Thor) for the actual specific skeleton generators to use.
Oskar Szrajer
@gotar
Jun 09 2016 06:38
nice :) it will help for sure new guys to start. But how much they will understand from code they will get it's another story. Adance user will probably have already his own dry-web skeleton
Tim Riley
@timriley
Jun 09 2016 08:00
@gotar yeah, that's right. The plan here would be to support both options: offer a couple of "standard" stacks from dry-rb for dry-web with roda and hanami, and then also let people build their own skeletons/generators and let them be installed via the same tool.
Piotr Solnica
@solnic
Jun 09 2016 09:23
tbf I’d hold off a bit with any generators until things are more stable
Tim Riley
@timriley
Jun 09 2016 09:25
@solnic I just want to offer some kind
Piotr Solnica
@solnic
Jun 09 2016 09:26
it’s gonna be valuable but let’s take into consideration the effort that will have to go into it :)
Tim Riley
@timriley
Jun 09 2016 09:26
of relatively straightforward way for people to get started
Yeah, I wasn't planning on making this a super big thing initially.
Piotr Solnica
@solnic
Jun 09 2016 09:29
gotcha
Oskar Szrajer
@gotar
Jun 09 2016 10:17
more valuable will be a set of blog posts that describe whole stack, for me it was quite hard to glue container, autoinject, rom-(repository) ...
if you generate code using those technology, users will open it and will not have idea what's going on. A lot of "magick"
Piotr Solnica
@solnic
Jun 09 2016 10:22
There should not be any need to glue things together. That's why dry-component was born as it does the gluing part for you. You just hit a wip interfaces and some issues related to partly finished stuff :)
Oskar Szrajer
@gotar
Jun 09 2016 10:48
yeap but using dry-component without understanding container and autoInject is adding layer of magic (or maybe I just like to work as low as possible ;])
it's like repository in rom for me, you can use it if you before learn commands, relations, mappers ...
without that you just add layer of magick you don't understand and don't now how it works that you can persist data
just by adding single line in repo
but maybe it's me, I'm quite strange type, do not like any generators or layers that hide low lovel code
Piotr Solnica
@solnic
Jun 09 2016 11:15
Finished in 5.98 seconds (files took 0.91828 seconds to load)
2224 examples, 0 failures, 40 pending
@fran-worley ^^^ :tada:
Oskar Szrajer
@gotar
Jun 09 2016 11:15
:)
Piotr Solnica
@solnic
Jun 09 2016 11:16
@gotar yeah I’m the same man so I hear ya, but most people are not like us, hence frameworks and automation
Oskar Szrajer
@gotar
Jun 09 2016 11:31
Yeah, it's always a matter of balance between magick and convenience
Piotr Solnica
@solnic
Jun 09 2016 11:50
I think we got it right
the only “magic” stuff is auto-inject since you gotta understand how module subclassing works
otherwise it will be totally magic for you
irb(main):006:0> Dry::Validation::Schema.config.predicates[:size?]
=> #<Dry::Logic::Predicate id=:size? args=[]>
irb(main):007:0> Dry::Validation::Schema.config.predicates[:size?].to_ast
=> [:predicate, [:size?, [[:size, undefined], [:input, undefined]]]]
irb(main):008:0> Dry::Validation::Schema.config.predicates[:size?].curry(2, [1,2]).to_ast
=> [:predicate, [:size?, [[:size, 2], [:input, [1, 2]]]]]
so this is really really cool ^^ kudos to @fran-worley for helping with this :)
and also this:
irb(main):011:0> is_empty = Dry::Logic::Predicate.new(:empty?, fn: String.instance_method(:empty?))
=> #<Dry::Logic::Predicate id=:empty? args=[]>
irb(main):012:0> is_empty.bind("foo").()
=> false
irb(main):013:0> is_empty.bind("").()
=> true
this is how we now grab custom predicate methods from a schema class and bind them once we’ve got schema object. so so cool :D
this is a huge improvement, we now have access to entire predicate registry while defining rules in the DSL which enabled things like verifying if definitions are correct
we’re gonna expand this verification more, for now the first baby step was to verify a) predicate name b) its arity
which is already a big UX improvement
Piotr Solnica
@solnic
Jun 09 2016 11:56
I also have an idea how to enable contextual validations, where predicates may depend on some state
Oskar Szrajer
@gotar
Jun 09 2016 11:57
there is a little magic in repo - how and why it define relation and commands, and why I got struct not tuple (hash)
Piotr Solnica
@solnic
Jun 09 2016 11:57
initially I thought it’s gonna be fine to use schema itself, but I think it’s too much now, it actually makes rule compilation more tricky if we want to avoid recompiling the whole thing every time you use Schema#with API sooooo, I’m gonna introduce a “context” API instead, and in your custom predicates you’ll simply have access to a context object, which can be anything, so ie you’ll be able to do schema.context(current_user: user).call(some_stuff)
and ie you may have a predicate def awesome?(context); # do sth based on context.current_user; end
and that’s it
this is relevant for Reform folks ^^ /cc @mrbongiolo @apotonick @fran-worley @mensfeld
Christopher Dennl-Ortega Arrieta
@cdennl
Jun 09 2016 12:20
yeah finally, custom predicates not related to keys
thats very nice @solnic when do you think it will be ready?
I know @apotonick waits for it desperately to release new reform version :D
And I would appreciate this feature as well :D
Piotr Solnica
@solnic
Jun 09 2016 12:43
@cdennl next week
Luca Guidi
@jodosha
Jun 09 2016 14:16
@solnic @fran-worley dry-rb/dry-logic#17 may have probably broke dry-v master. Try to run dry-v specs by depending on dry-logic master. All the examples fail.
Piotr Solnica
@solnic
Jun 09 2016 14:17
@jodosha right, lemme merge 180, it’s green there
Luca Guidi
@jodosha
Jun 09 2016 14:17
<3
Fran Worley
@fran-worley
Jun 09 2016 14:37
@solnic have we chucked in a spec to check that custom predicates actually work without args?
For dry-rb/dry-validation#160 oh and I think the PR/ issue on custom args in message names could go too.
This one: dry-rb/dry-validation#114
Fran Worley
@fran-worley
Jun 09 2016 14:42
@cdennl the last I heard from @apotonick was that rules unrelated to keys didn't actually make sense. You want dry-rb/dry-validation#160 for the discussion.
Maciej Mensfeld
@mensfeld
Jun 09 2016 14:46
@solnic good change!
btw this does not seem to work:
      rule(author_presence: %i( author severity )) do |author, severity|
        severity.included_in?(%w( line file dir )).then(author.schema(Author))
      end
I cannot combine rules with schema requirements
Maciej Mensfeld
@mensfeld
Jun 09 2016 14:55
it seems that rules dont work in subschemas or i;m doing something wrong
Piotr Solnica
@solnic
Jun 09 2016 14:57
@mensfeld uhm I thought I added support for this syntax, report an issue
Maciej Mensfeld
@mensfeld
Jun 09 2016 14:58
@solnic in a released gem or on github only? ;)
Piotr Solnica
@solnic
Jun 09 2016 14:58
@mensfeld released gem
Maciej Mensfeld
@mensfeld
Jun 09 2016 14:58
I use the released version because I use it from gems
ok - will investigate it a bit further to be sure that it's not my fault
and if it is not I wil create an issue
btw @solnic should that work?
      key(:authored_at) #.required(:date_time?)
      rule(authored_at_presence: %i( authored_at severity )) do |authored_at, severity|
        severity.included_in?(%w( line file dir code )).then(authored_at.str?)
      end
because it seems that rules aren;t executed at all in sub schemas
yeah non of my rules work when they are in a schema that is being used as a part of a bigger schema
Piotr Solnica
@solnic
Jun 09 2016 15:03
you need required(:date_time?)
do key(:authored_at) { date_time? | str? } since that’s your base expectation
then do the detailed one in the high-lvl rule
Maciej Mensfeld
@mensfeld
Jun 09 2016 15:04
this example is a bit wrong - I want authored_at to exist and be date_time? only when severity is in given types
I don't want to make it required
well I want - but only when severity is in those types
Piotr Solnica
@solnic
Jun 09 2016 15:05
optional(:authored_at).required { str? | date_time? }
Maciej Mensfeld
@mensfeld
Jun 09 2016 15:07
Good one but does not solve problem of rules that arent executed when a schema is a subschema :(
all my schemas work when used directly
but then a subschema - none exceuted
debugging...
This message was deleted
Piotr Solnica
@solnic
Jun 09 2016 15:10
@mensfeld just report an issue with a repro, I don’t have time to look into it now but will do later
Maciej Mensfeld
@mensfeld
Jun 09 2016 15:10
ok :)
Tim Riley
@timriley
Jun 09 2016 22:32
Those dry-v changes are looking excellent! 👏🏻