Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 22:22
    patrickclery edited #362
  • 22:21
    patrickclery commented #361
  • 22:11
    patrickclery commented #361
  • 22:11
    patrickclery commented #361
  • 15:43
    FioFiyo starred dry-rb/dry-types
  • 11:52
    flash-gordon commented #361
  • 07:09
    unixc3t starred dry-rb/dry-types
  • Oct 22 22:33
    patrickclery commented #361
  • Oct 22 21:12
    D1mon starred dry-rb/dry-matcher
  • Oct 22 15:44
    graudeejs starred dry-rb/dry-container
  • Oct 22 08:41
    esparta commented #366
  • Oct 22 08:39
    flash-gordon commented #366
  • Oct 22 08:39

    flash-gordon on master

    Fix error on Dry::Types::Array#… Merge pull request #366 from es… (compare)

  • Oct 22 08:39
    flash-gordon closed #366
  • Oct 22 08:38
    flash-gordon closed #362
  • Oct 22 08:38
    flash-gordon commented #362
  • Oct 22 08:37
    flash-gordon closed #361
  • Oct 22 08:37
    flash-gordon commented #361
  • Oct 22 07:48

    solnic on master

    Adding missing built-in predica… Merge pull request #65 from esp… Merge branch 'release-1.0' (compare)

  • Oct 22 07:47

    solnic on release-1.0

    Adding missing built-in predica… Merge pull request #65 from esp… (compare)

Piotr Solnica
@solnic
there’s a bit more to it, but it’s a bigger subject: validation hints :)
in the near future we’re gonna have a way to generate user-friendly representation of validation rules, even for those that were not used in the validation process
Tim Riley
@timriley
Yeah, that sounds handy!
Piotr Solnica
@solnic
so ie when you have age.int? & age.gt?(18) and it turned out to be an empty string we still need to provide meaningful info to the user
since we have access to all the rules we can simply use the same technique to produce validation hints (as I call it)
we can automatically drop type expectations, since it’s too low level IMO, and just do things like gt?(18) => “age must be greater than 18”
Tim Riley
@timriley
Wonderful :)
Piotr Solnica
@solnic
we can actually be pretty precise here, and take into consideration whether or not a value was present
so ie pattern match on input and have things like “oops, you forgot to fill in age"
or “hey, sorry but your age must be greater than 18, you gotta wait 2 years” :D
hints will be useful when there are many rules though, so we want to be smart and display only what’s relevant to the user
ie displaying ‘age can’t be blank’ and ‘age must be greater than 18’ is redundant from the user pov
I mean the former msg is redundant
since the latter implies the former
Tim Riley
@timriley
Yeah. Many of those decisions you could make programatically, but in some schemas, it may be hard to guess correctly.
Piotr Solnica
@solnic
common stuff should be simple
filled? vs more specific predicates is a good example, I think
so ie if filled? failed but we have more rules, then we’re gonna be interested in error msgs for the other rules
or I should say, validation hints, those won’t be errors since filled? failure is the only error when a value is blank, the rest is just providing hints for the value and its constraints
actually, it’s probably a good idea to always ignore filled? failure when there are other rules, can’t think of any reason why you would want to display age cannot be blank + more info about other rules
Tim Riley
@timriley
Yeah.
Filip Bartuzi
@Bartuz
hello
Piotr Solnica
@solnic
hey ho
Filip Bartuzi
@Bartuz
have you already started working on i18n support? Is there dedicated branch for that?
Piotr Solnica
@solnic
not yet
Filip Bartuzi
@Bartuz
Ok, great. I would like to contribute
Piotr Solnica
@solnic
cool! I gotta clean up current error compiler and come up with some common interface so that buiding new compilers will be simple
we talked with @AMHOL that maybe it’s gonna be possible to only have Messages and its sub-classes for specific backends
so that we only have one compiler and it calls messages#lookup and passes all the info that might be needed to get a string message from some backend
Filip Bartuzi
@Bartuz
Piotr, you use dry-validation is rails based projects, right?
Piotr Solnica
@solnic
no, I don’t use it yet in anything ‘real'
I started using it in rodakase-blog sample app though
but nothing fancy yet
Filip Bartuzi
@Bartuz
I will appreciate any kind of example. I'll have a look on https://github.com/solnic/rodakase-blog later
Piotr Solnica
@solnic
@Bartuz what kind of examples?
Andy Holland
@AMHOL
@solnic nice work xD
What was the thinking with going with Schema#call(data).messages rather than just having Schema#call(data) return formatted messages?
Piotr Solnica
@solnic
@AMHOL you’re gonna need more info than just messages
errors vs hints etc
also, some people may want to take that and process further (ie in reform)
so I’m taking those use cases into consideration already
Andy Holland
@AMHOL
Ahh, OK, cool :)
Piotr Solnica
@solnic
@AMHOL mergy-mergy? :joy:
Hannes Nevalainen
@kwando
@solnic should one prefer call_sheet over transflow? Seems to be quite similar
Piotr Solnica
@solnic
I pushed i18n branch to dry-validation, gonna “prepare the ground” there, maybe add some super basic functionality too, happy to get some help later on with it /cc @AMHOL @Bartuz
lots of things to consider, so I’ll open a PR early so we could discuss in async mode too
Andy Holland
@AMHOL
@solnic not sure what you think, but we could avoid symbolize_keys by using :key: value in YAML files?
Piotr Solnica
@solnic
more typing in yaml, I think it’s valuable to simply convert to symbols, it’s not too complex
alternatively we could lookup by strings
Andy Holland
@AMHOL
That could work