These are chat archives for dry-rb/chat
Next-gen ruby libs! » github.com/dry-rb » website: https://dry-rb.org » forum: https://discourse.dry-rb.org
i’m working thru the
workshop-app, and can’t figure out this error:
$ bundle exec rspec An error occurred while loading ./spec/admin/unit/articles/form_schema_spec.rb. Failure/Error: require "blog/admin/articles/form_schema" Dry::Container::Error: Nothing registered with the key "#”
require "dry/validation" require "types" module Blog module Admin module Articles FormSchema = Dry::Validation.Form do required(:title).filled(:str?) required(:status).filled(type?: Types::ArticleStatus) optional(:published_at).maybe(:time?) end end end end
module Types include Dry::Types.module ArticleStatus = Strict::String.enum('draft', 'published', 'archived') end
what’s going wrong here?
type?: Types::ArticleStatusin the workshop exercises I ran people through
Hi, I have a problem with
I want to test a transaction who have
Redis connection for pub/sub and cache.
I have a
RedisContainer who register the redis instance, and I have
CacheContainer who have the logic about publishing and caching.
My transaction have
include Dry::AutoInject(RedisContainer)['redis_instance'] include Dry::AutoInject(PublishContainer)['publisher'] include Dry::AutoInject(CacheContainer)[cacher: 'cache.increment'] . . . def publish(input) publisher.('hit:created', input[:hit].id, instance: redis_instance) end
I don't want to my transaction to be dependent about my
RedisContainer, but I need it for my spec, any idea?
module CacheContainer extend Dry::Container::Mixin merge RedisContainer end
@solnic ty for the clarification re:
that said, the above feels to me like pushing too implementation details onto the client vs the way i had expected it to work:
The latter is also more consistent with the way built in types work.
I’d expect the type itself to be able to say if something was a valid instance (eg, this is how the
sanctuary-def project works), and then the
FormSchema would be delegating to that, and my original code would be a one liner to implement within the Schema lib code. Whereas here the client of the form schema needs to know how enums work and manually write part of the validation. Do you agree this is not ideal or am I missing something?