dry-schema
dry-schema copied to clipboard
Deeply nested recursive attributes
Hi, i'm using v 0.11.0 in hanami framework. I have following params:
{
"body": {
"type": "doc",
"content": [
{
"type": "paragraph",
"content": [
{
"type": "paragraph",
"content": [
{
"type": "text",
"text": "something"
}
Each 'content' param contains repeatable attributes from previous section. I'm trying to do something like this:
sch = Dry::Validation.Form do
required(:type).value(included_in?: ALLOWED_TYPES)
optional(:content).each do
schema( # -- HERE I NEED TO CHECK THE SAME ATTRIBUTES --)
end
end
Is it possible to call recursively the same schema?
Hey, this is not supported, but that's an interesting use case. Is there a limit how deep this can go?
@solnic Thanks for your response. In my case there is max 5 nested levels. For better understanding I'm using https://tiptap.scrumpy.io/export lib on frontend that generates JSON with nested elements according to user's post formatting. But I think it would be great if there will be ability to iterate & validate all received nested content without knowing exact nesting levels
@vrtsev this is something that we can consider to add in the future. We'll see if more people ask about it.
ps. I moved your issue from dry-validation to dry-schema because this is the new engine for schema DSL and it's used in dry-validation 1.0.0 (soon to be released).
👍 I'll add my vote to the mix. I was trying to accomplish something similar with dry-types
.
class A < Dry::Struct
attribute :type, Types::Coercible::String.constrained(eq: "a")
attribute :child, self | B
end
class B < Dry::Struct
attribute :type, Types::Coercible::String.constrained(eq: "b")
attribute :child, self | A
end
class Z < Dry::Struct
attribute :type, Types::Coercible::String.constrained(eq: "z")
end
class Root < Dry::Struct
attribute :child, A | B | Z
end
Root.new({
child: {
type: "a",
child: {
type: "b",
child: {
type: "b",
child: {
type: "a",
child: {
type: "z"
}
}
}
}
}
})
I've just run into the same issue trying to make a dry-schema for a node in a decision tree, so +1 from me
I would use this feature too.
Same as the guys above.
+1
+1 here
If any of you folks would like to have a go at implementing this, I'd be happy to support you.