-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow oEmebed fields to be queried as "raw" or "rendered" #150
Comments
Thank you for suggesting these features. I'm using the oEmbed field for essentially storing urls of videos and other embedded media. The reason why this field is great in the back end is that you get a preview. However on the front end you often want the source url. Consider having a YouTube video you may want the iFrame, but you often also want a link to go to the YouTube page itself. (The src of the iFrame is not the correct YouTube page url so you can't parse it from the html). In a custom front end I (and trans I work with) have normally created a custom plugin to deal with all the r embedded media. Players like React Player work very well and are predictable with many different display options. Often people want to embed something that doesn't automatically get iFrame html. The front end can deal with this easily with the url. With an image you have access to multiple things like secSet and source url. Something like this would work well in the returned graphQL if that is possible. |
I see 2 options forward here: 1: provide an argument on the field, like: myEmbedField( rendered: TRUE ) or myEmbedField( rendered: FALSE ) 2: change the shape of the field (breaking) that returns both fields: myEmbedField {
rendered
raw
} The former I think we can do in a non-breaking way, supporting both features and letting the client chose how to format the response. And via GraphQL Aliases the client could ask for both formats: renderedEmbed: myEmbedField( rendered: TRUE )
rawEmbed: myEmbedField( rendered: FALSE ) |
my preference would be the second option - though having just looked through the current output i can see it may introduce breaking changes. Option 2 seems very useful, there are instances where i have wanted to use an iframe and the url (i.e. show the embed and put the link next to if if someone actually wants to go to the youtube site). Personally i'd do this via something like React Player, but others may want the iframe code. Option 2 makes this much more similar to the image field - where you have a number of types of data you can receive (eg scrSet, sourceUrl, etc). Passing options to a field makes this one slightly unusual and perhaps less beginner friendly, plus as a developer its very useful to compare output in GraphiQL but including different options without passing options. Is there perhaps a 3rd way (if you want to avoid breaking changes) where an option could be passed so we provide all potential options: |
What problem does this address?
Oembed fields used to (in v0.6.* and prior) return the raw URL that was input to the field.
In v2.0, oembed fields return the "rendered" iframe embed.
Some users like the new functionality, but some prefer the old and want their client application to generate the embed.
What is your proposed solution?
Provide an argument on oembed fields allowing the client to decide how the field should be returned.
Similar to the
content(format:RAW)
orcontent(format:RENDERED)
argument on content/title fields.This would allow clients control of how the data is returned for their use case.
What alternatives have you considered?
Add a setting on the server allowing the server to configure the return type. This limits the client's flexibility, but might be worth considering still.
Additional Context
see: #106 (comment)
The text was updated successfully, but these errors were encountered: