Next-gen ruby libs! » github.com/dry-rb » website: https://dry-rb.org » forum: https://discourse.dry-rb.org
Glad to hear it!
As far as things I'd like to see, I've always found permissions/access to be poorly organized in most applications. I've often thought about using the container concept to inject validations and access policies dynamically on a per-request basis, but I would be curious what strategies you've found for appropriately isolating those concerns in an extendable way.
# request 1
container.register(:request, request)
# request 2
container.register(:request, request)
# request 1
container[:request].redirect '/home' # request 2 user gets redirect
@timriley could you be more specific about which "objects" you are thinking about?
@AMHOL you're right, it would be unfortunate to depend on the full build-up and tear-down of the entire world on each request
MyContainer['validate_article']
I would inject MyArticleValidationResolver.new
into any operations that needed it?
validator = validator_resolver.(params); validator.(params)
def self.Schema(base = Schema, **options, &block)
Instead of :
time_op = TimeMath().ceil(:week).advance(:hour, 10)
What about :
T=TimeMath()
T().next_week + T(10).hours
#success?
and #failure?
for that
monad
word with sutin more usual
{data: [{_type: 'user', ...}, {_type: 'group', ...}]}
is there a way to get dry-types to pickup on the _type
property for each returned entity and properly deserialize the json into the correct objects?
dry-result_matcher
and dry-monads
, how would you handle two different failure scenarios? For example, say that you are updating a record and you need to retrieve the record from the DB before updating it. If the record is not found you want to return a 404 status code and if the update is not successful, you want to return the status code 422 + error payload.put '/people/:id' do
UpdatePerson.new(declared(params, include_missing: false)) do |m|
m.success do |person|
person
end
m.failure do |errors|
# check the content of Left and decide?
status 422
errors
end
# code another block to handle 404?
end
end
pick up on the _type
property
data
it came across {_type: 'user', name: 'bob'}
it would create an a new instance of User, basically doing User.new({_type:'user', name: 'bob'})
I want to validate the following yaml file using dry-validation 0.7
remote_printer:
pusher:
secret: 'xxx'
key: 'yyy'
pid: '1'
presence: 'zzz'
labels_printer:
name: 'ZEBRA'
port: 'COM4'
receipts_printer:
name: 'BIXOLON'
port: 'COM5'
labels_printer and receipts_printer are optional, but when any of them is present I need to validate that name and port are present too. Any hints?
optional(:labels_printer).schema { key(:name).filled(:str?); key(:port).filled(:str?) }
optional(:labels_printer).schema(PrinterSchema)