Closed Kethatril closed 3 years ago
I think this should be possible! I believe you should able be able to use attrs
vizyField {
nodes {
... on VizyNode_Paragraph {
attrs
}
}
}
Which is essentially the information stored for the node in the database anyway. It just get's a little tricker with nested marks, but they're also available via marks
.
Does that help?
From my experience attrs
and marks
are always empty for the built in nodes e.g.
{
"type": "paragraph",
"content": "<p>This is some content, it <strong>supports <em>content blocks</em></strong>, and rich <strong>text</strong>.</p>",
"attrs": "[]",
"marks": "[]",
"tagName": "p"
},
for this query
... on VizyNode_Paragraph {
type
content
attrs
marks
tagName
}
Gotcha, I see what you mean now. So yes, the content
property will be the HTML-rendered string, but if you want full control over rendering it, I'd suggest using rawNodes
which I've just added to the craft-3
branch. I've also made some fixes with some of those attributes not containing correct values, along with renaming content
to html
, and content
now containing JSON content. Check the updated docs.
To get this early, change your verbb/vizy
requirement in composer.json
to:
"require": {
"verbb/vizy": "dev-craft-3 as 1.0.3",
"...": "..."
}
Then run composer update
.
As for being able to query with children
that's a little tricker, and I'll put some work towards that. The tricky part will be dealing with nested marks.
You might also be interested in the https://github.com/enVolt/prosemirror-to-html package, which takes the JSON stored by Vizy and convert it into HTML client-side.
Fixed in 1.0.4
What are you trying to do? I am currently attempting to replace some built in node types and marks with React components when rendering the result of a vizy graphql query in React.
What's your proposed solution? Currently when you use graphql to query the content field of a built in node (e.g.
VizyNode_Paragraph
) the field is returned as rendered html. Would it be possible to add a field that allows for querying the children nodes that make up the default node types (I can see how this would be tricky with nodes nested inside nodes though)I have looked at just using the rawNodes directly at the root of the field, however that doesn't have usable type information for custom blocks, and also doesn't have any data for relationships other then id (for assets, entries etc)