Next-gen ruby libs! » github.com/dry-rb » website: https://dry-rb.org » forum: https://discourse.dry-rb.org
things are happening in dry-data:
irb(main):010:0> Dry::Data['strict.string'].constrained(format: /^f/)['foo']
=> "foo"
irb(main):011:0> Dry::Data['strict.string'].constrained(format: /^f/)['boo']
Dry::Data::ConstraintError: "boo" violates constraints
it uses…dry-validation rule system :)
@AMHOL ^
that plus defining types under constants
That's pretty cool, also nice that both these libraries are enhancing each other :)
I suspect I’ll extract core stuff from validation to dry-predicates or sth
there are some really cool things that can be done with constrained types
ie you can build a data generator that would create random data based on constraints
constants are cool too in this case, since you can do things like
Types::Optional | Types::Strict::String
ie
Bool is actually defined like this
Types::Strict::True | Types::Strict::False
gonna add a built-in
Enum type too, I need it
I will finally have a place for defining various app core concepts as types
wdyt about an interface like that for enum:
States = String.enum(%w(draft published))
ugh, lunch time, bbiab :)
OK TTYL :wave:
would it be unreasonable of
Dry::Data['hash'].schema to support nested hashes?
schema = Dry::Data['hash'].schema(
username: 'string',
accounts: {
skype: 'string'
}
)
^^ I thought that was going to work
schema = Dry::Data['hash'].schema(
username: 'string',
accounts: Dry::Data['hash'].schema({
skype: 'string'
})
)
that works as expected
statuses = Types::Strict::String.enum(“draft”, “published”, “archived”)
statuses[1] # => “published”
statuses[“published”] # => “published”
statuses[“#trollface”] # => ConstraintError
statuses[nil] # => ConstraintError
@AMHOL ^^ :dancer:
oh wait, values array is frozen, gotta freeze values themselves too
FREEZE ALL THE THINGS
Saw https://github.com/dryrb/dry-data/commit/81dd5d57748fa9f33e9eaa690cdf64de7047d7ea#diff-fb782add039323965a06e9b806b5fc45R81 and wondered why the first call to values was frozen :p
only the first
but why call it
freeze!, let’s surprise people
gonna monkey patch
freeze! and make it raise an error “sorry, due to the climate change we can’t freeze anything"
“try Object#melt instead"
@AMHOL ^^ how does that sound?
@AMHOL I dunno, stupid right, I’ll remove this sentence after I finish adding support for sum-types in enum :joy:
I’m in the middle of writing a spec for it
string.enum(tea | coffee)
sth like this will work
I think O_o
Yeah, doesn't make sense does it
I think enums of symbols/classes would be useful
although we don’t have Class type either
ok abandoning the idea of sumtype for enum
doesn’t feel like it makes sense, plain sum-type is enough
@AMHOL I added symbol and class, let’s see if people will use those
ok, gonna run specs in my app to see if I haven’t screwed up anything
seeing first
F already :joy:
victory, kind-of
I’ve got a spec that fails only on my machine
from time to time
like, every 6th time
it’s probably some awkward leftover in the db between the spec runs
since it’s a feature spec...
@AMHOL I like the fact integrating with dry-validation took 10LOC
Took me ages to un-see it :joy:
@solnic what does the i18n gem actually do beyond a container for a hash of translations and the ability to resolve those with a hash of arguments to interpolate?
@AMHOL it actually supports few backends, like storing stuff in the db etc
it’s quite a lot of functionality
Here’s one attempt I found at an i18n replacement: https://github.com/ai/r18n
still a lot of work tbd though, but functionality is already pretty good
btw I was wondering what kind of interface would be nice for a struct constructor that selects a struct class or its sub-class based on attributes
kind-of like STI in AR where a given field determines the type