Support third-party fragments #17
Comments
|
thank you. this one may need some thinking but its not impossible |
|
got some sample code i can work with? |
diff --git a/README.md b/README.md new file mode 100644 index 0000000..52ab4a6 --- /dev/null +++ b/README.md @@ -0,0 +1,17 @@ +# Example repo for [babel-blade/babel-blade#17](babel-blade/babel-blade#17) + +## `framework.js` + +This represents an imaginative third-party framework. We don't have control over this framework's code. + +The framework exports an `Image` component, which renders an image with some props. + +To ease the usage of this component with the framework's graphql API, it also exports a `query` function. This function is a wrapper for the user's query that adds a fragment for all the data the image needs. + +A real example for this would be [Gatsby](https://gatsbyjs.org/)'s [`transformer-sharp`](https://www.gatsbyjs.org/packages/gatsby-transformer-sharp/) plugin. Similarly to our imaginative framework, it adds a fragment to all queries. This can be used to query for the [`image`](https://www.gatsbyjs.org/packages/gatsby-image/) plugin's props. + +## `index.js` + +This represents our own code, which we want to use `babel-blade` on. It imports the framework's `query` function, so it can use the `FrameworkImage` fragment in its query. + +However, with `babel-blade`, there is currently no easy way to use this fragment. diff --git a/framework.js b/framework.js new file mode 100644 index 0000000..b56e9e5 --- /dev/null +++ b/framework.js @@ -0,0 +1,24 @@ +export const Image = ({ image }) => ( + <img + src={image.src} + alt={image.alt} + width={image.size.width} + height={image.size.height} + /> +); + +const imageFragment = ` + fragment FrameworkImage on Image { + src + alt + size { + width + height + } + } +`; + +export const query = gql => { + gql += imageFragment; + return fetch(gql); +}; diff --git a/index.js b/index.js new file mode 100644 index 0000000..9bfdf98 --- /dev/null +++ b/index.js @@ -0,0 +1,15 @@ +import { Image, query } from "./framework"; + +const pageQuery = ` + query { + page { + image { + ...FrameworkImage + } + } + } +`; + +export default () => { + query(pageQuery).then(data => <Image image={data.page.image} />); +};
|
Sure, I created a quick example repo to better illustrate the problem: https://github.com/jgierer12/babel-blade-17 I think the implementation of this feature would be trivial, we simply have to add the name of the fragment to the query. But it is incompatible with the current API, since all string parameters after the first one are assumed to be decorators. If you would be willing to introduce a breaking API change for this, making the second parameter an array of decorators instead would make sense. Otherwise, perhaps something like data.field(args, ...decorators)(fragment)might work. |
|
yes i am willing to introduce a breaking API change. this is still early days :)
actually not true, i think. did you read this somewhere? it used to be the case, but now you can do data.field('@sort', 'foo: 1', '@delay', 'bar:2')and it'd work out to data {
field(foo: 1, bar: 2) @sort @delay {
// ...
}
}nice, eh? proof but it maybe too nice. i'm willing to break that flexibility for a bit more predictability and third party/inline fragments. in terms of having curried functions like you propose it would introduce extra complexity. i propose this: data.field(subfields, args, decorators)all three args would take either null, strings, or template strings. subfields include fragments but also any other fields the user doesnt need to actually use in the js at that point in time. Funny enough, this was the original API design, and i broke it to go for the flexibility which seemed like a good idea at the time. While I originally didnt like asking users to memorize the three arguments (and also putting in |
Ah, I didn't know it works like that. That is very cool indeed! I actually don't remember where I got that from, I think you may have said it in the video? Anyways, I like your proposed API. Being able to manually pass in fields, not just fragments, surely would be useful too in some situations. I suggest all three args can also take arrays of their supported types, so you can for example mix inline fragments and blade-generated ones. |
|
ah. very interesting. sure thing. |
|
closing as i am no longer maintaining this - seeking maintainer! #23 |
Sometimes, it is necessary to include third-party fragments, such as
gatsby-transform-sharpsGatsbyImageSharpFluidfragment required by thegatsby-imagecomponent. As far as I can tell, it's currently impossible to use this in a blade-generated query.The text was updated successfully, but these errors were encountered: