dry-rb/chat

WE MOVED TO ZULIP => https://dry-rb.zulipchat.com <=

Tonni Tølbøll Lund Aagesen

@ta

@flash-gordon like this: https://gist.github.com/ta/5b118b6f48b9a5916647cd12bee67db5 ?

Nikita Shilnikov

@flash-gordon

similar but I think you want to nested structs rather nested schemas

class MyStruct < Base
  attribute :id, Types::Strict::Integer
  attribute :data do
    attribute :code, Types::Strict::Integer.optional.default(nil)
    attribute :msg,  Types::String.optional.default(nil)
  end
end

like that^

Tonni Tølbøll Lund Aagesen

@ta

MyStruct.new({"id" => 1, "data" => { "code" => 200 }}) still doesn't set the code attribute :/

Nikita Shilnikov

@flash-gordon

lemme look into this

Tonni Tølbøll Lund Aagesen

@ta

but thanks for the nested structs hint :)

cool

Nikita Shilnikov

@flash-gordon

change, attribute :data do to attribute(:data, Base) do

because it's not usign Base as default there but Dry::Struct

Tonni Tølbøll Lund Aagesen

@ta

yes, was about to write that solution :)

can there be an argument for having nested structs inherit from parent struct?

Nikita Shilnikov

@flash-gordon

we could have a means for that

I'm not sure what's the best here but having something would be nice

I came across this pattern a copule of times

Tonni Tølbøll Lund Aagesen

@ta

Thanks for helping out

oh btw, can a nested struct be optional like a nested schema?

Nikita Shilnikov

@flash-gordon

you mean absence of key or nil as a value?

Tonni Tølbøll Lund Aagesen

@ta

I have Types::Hash.schema( ... ).optional.default(nil) in some structs

Nikita Shilnikov

@flash-gordon

class MyStruct < Base
  attribute :id, Types::Strict::Integer
  attribute :data, Class.new(Base) {
    attribute :code, Types::Strict::Integer.optional.default(nil)
    attribute :msg,  Types::String.optional.default(nil)
  }.optional
end

that's the closest thing I can think of

and that's not good enough

feel free to post both suggestions to GH and we'll sort it out eventually

Tonni Tølbøll Lund Aagesen

@ta

will do, thx

Tonni Tølbøll Lund Aagesen

@ta

oh my, what one can learn from reading the docs more closely: Types::Hash.schema(name: Types::Strict::String).with_key_transform(&:to_sym) :)

Nikita Shilnikov

@flash-gordon

yeah, if you don't need structs you can use schemas, they also support kind of inheritance

I prefer DSL for describing structs, this is basically it

Jaromír Červenka

@Cervajz

Off topic: Anyone heading to ElixirConf in Prague? :)

Oskar Szrajer

@gotar

Hi, I'm trying to validate something like this in dry-v. a field values is any array of strings, if inside those array there is a value 'foo' it must validate presence of 'bar', 'baz' too, so something like
values.include?('foo') > values.include?('bar') & values.include?('baz')

is it possible? I don't have any good idea how to achieve this

Vasily Kolesnikov

@v-kolesnikov

I would prefer to avoid that validation at all, even if dry-v could do it. It sounds strange to have data like unstructured array of strings. Could you give a real example of usage the data like that?

Oskar Szrajer

@gotar

User select answers in a form, it's a checkbox (multiselect) is he select one from them he must select some others.

I found some solution, just a custom predicate, works ok-ish ;]

Vasily Kolesnikov

@v-kolesnikov

:ok_hand:

Oskar Szrajer

@gotar

and I'm building this for existing form, cannot change logic/form there

Ariel Valentin

@arielvalentin

Hello friends. Pitor recently invited me to collaborate on dry-system-rails. I have kept most of my comments in the discourse forum or pull requests. Are those still the best place to discuss design/code changes? What is appropriate to discuss here?

Tim Riley

@timriley

@arielvalentin both of those places are better than here, yep. I’d keep doing what you’re doing.

Ariel Valentin

@arielvalentin

Thank you @timriley !

Trey Pendragon

@tpendragon

Hey all. I was wondering if there's a plan for a 1.0 release of the dry ecosystem?

Our community has started using it, and we've had a system in production using it instead of ActiveRecord and the like for the last year, but it'd be nice to be able to rely on semver.

Nikita Shilnikov

@flash-gordon

@tpendragon is it that important? :) A few things to keep in mind

the API is pretty stable already and we try to make all the changes in a backwards compatible manner

Trey Pendragon

@tpendragon

I agree, you've done a great job. Is it a problem to just cut what exists as 1.0.0 and keep on doing that?

Nikita Shilnikov

@flash-gordon

second, we coordinate our releases with hanami's ones, that means if for any reason we'll need breaking changes (unlikely) this will give us some freedom. Still, we follow semver so this shouldn't be a problem

but we do have checklists for 1.0s

Trey Pendragon

@tpendragon

Working for Universities, we tend to put a lot of stock in specifications, so I just know it would make a number of my colleagues more comfortable were things like dry-types and dry-struct to have the commitment behind them that comes with 1.0. Otherwise, while you've done a great job, technically you're outside the realm of responsibility yeah?

If you're not comfortable with it I understand, I know it's a daunting thing. Do you have a link to the checklist of requirements somewhere? Maybe I can help.

Nikita Shilnikov

@flash-gordon

as I said, it's a matter of coordination, otherwise I'd push 1.0 and call it a day :) I don't think there's a big issue with how you number your gems as long as you follow semver. What I can say, it's dry-types is expected to be the next 1.0 release since it's mature and stable. But we do have plans to introduce some (non-breaking I hope) changes before that.

Trey Pendragon

@tpendragon

Okay. :) I'll keep an eye on it. We're about to release some code that depends on 0.13 of dry-types, so I look forward to seeing what's coming up.

Thanks!

Manic Chuang

@manic

Hi guys, it seems that I maybe encounter a bug of dry-types SUM, but I'm not sure. Could you help me on this?

It happens when I try to verify a object which should be a hash or a string

test = Dry::Types['hash'].map(Dry::Types['symbol'], Dry::Types['strict.string']) | Dry::Types['strict.string']
test[a: 'b'] # passed as expected
test['a' => 'b'] # should fail but pass!
test['test'] # passed as expected
test[12345] # should fail but pass!

I'm wondering if there is anything that I didn't notice or I use the wrong way to build my rule. Thanks :)

Where communities thrive

People

Repo info

Activity