Next-gen ruby libs! » github.com/dry-rb » website: https://dry-rb.org » forum: https://discourse.dry-rb.org
Hello all! It’s been a while since I looked at ROM/dryrb…
I’m starting a greenfield app which requires a REST api, and thought of using Roda + ROM.
However, I have only seen passing tweets about dry-web :)
...and wonder what the status of it is?
Is it expected the API is fairly stable now? docs?
No high-level docs for dry-web, unfortunately, @adz. We have an application generator via the dry-web-roda gem, though:
dry-web-roda new my_project
APIs aren’t all fully stabilised, but they’re working an in production.
btw, released rspec matcher for dry-types (dry-struct in future) https://github.com/matic-insurance/rspec-dry-struct
it's dead simple, but can be extended
Hmm.. thanks @timriley
I’ll have to have a look through what’s included...
I’ll have to have a look through what’s included...
confusing dry-view thing: when you just so happen to have a partial name the same as a method/attribute on a view part… and you’re expecting the latter to be called (but instead get the partial rendered and lots of unexpted errors)
Is this not valid any more?:
TournamentTableSchema = Dry::Validation.JSON do
required(:type) { filled? > str? }
end
TournamentTablesSchema = Dry::Validation.JSON do
required(:_embedded).schema do
required(:tournament_results).each do
schema(TournamentTableSchema)
end
end
endRaises an ArgumentError input_processor_compiler.rb:66:invisit_implication': wrong number of arguments (given 2, expected 1) (ArgumentError)`
This works:
TournamentTableSchema = Dry::Validation.JSON do
required(:type).filled(:str)
end
TournamentTablesSchema = Dry::Validation.JSON do
required(:_embedded).schema do
required(:tournament_results).each do
schema(TournamentTableSchema)
end
end
endSo the error occurs when a block is given to required in a sub schema.
@stigchristian
filled? > str? this is not correct (regardless of the crash, which is a bug) as it means that if it’s filled then it must be a string, if it’s not filled, then it’s valid too
we’re moving away from inferring coercions (which is what that ‘input_processor_compiler’ does) so I won’t be fixing this bug
you want
required(:type).filled(:str?) which means it a) must be filled b) it must be a string
there are a couple more things I gotta clean up, some things should be moved from container to component. This will simplify container’s code quite a bit
What parts from dry-container would move, do you think?
components should be more namespace-aware and should expose APIs related to that
like are you namespaced? gimme your ns name, pls. gimme your import-key name, gimme your fully qualified id etc
That's what happens when you try to map csv in to the ruby object directly
Thanks @solnic . dry-* is such an awesome collection of gems.
Is it possible to have dry-initializer alongside with dry-types? For example, if I have a class that is constructed by dry-initializer and there is a method that builds another class for dry-type attribute
@janjiss I’d expect both libs to work together w/o any issues (IIRC dry-initializer supports typed attributes already)
Sorry to formulate more clearly, can I use Dry::Types::Struct with the dry-initialiser?
It throws an error with missing key if I dont assign the attribute in the initialization. I sort of want fancy attr readers and writers, if that makes sense
ah, I’ve no idea, dry-types struct are going through a redesign process in dry-struct (not released yet). I initially built it only for my use cases in rom-rb, but people would like to use them in different contexts, so default strict behavior (all keys are required) isn’t really working in various cases, so we’re expanding the API in dry-struct
Got it :) I’ll probably will try to tinker with default values
@janjiss try setting
constructor_type(:schema) in Struct class
this won’t require all keys, but then there are funky cases where defaults aren’t being set and stuff like that, just see if it works for you (it may)
option :user_info, default: proc {map_user_info}
def map_user_info
user_info = UsersImport::Dtos::UserInfo.new()
end
no need for assignment :D
just came to say, that I enjoy
dry-types so much! making structs behave like a type with the same interface is AWESOME!
@janjiss
class Address < Dry::Types::Struct
attribute :street, Types::Strict::String
# other attributes
end
class Customer < Dry::Types::Struct
attribute :address, Address.optional
end
so types algebra works for structs as well
Im experimenting with Maybe, anyone has an idea how to set up Struct to be a maybe?
you can set
.constrained as well as .constructor for struct as well as for types
@Kukunin Little correction
Address.maybe actually creates a monad :)
@Kukunin That pointed me in the right direction anyways, so thank you very much for that :+1: