Skip to content
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

[graphql-tag/loader] It is really necessary to emit so much runtime code in each file #249

Open
langpavel opened this issue Apr 8, 2019 · 8 comments

Comments

@langpavel
Copy link

If I have 50 query files, emitting runtime code in each file is really ugly :-)

@dobesv
Copy link
Contributor

dobesv commented May 3, 2019

Can you describe the runtime code you are referring to? Is it just the little functions that pull together the required fragments into the document along with the query/mutation in it?

@langpavel
Copy link
Author

langpavel commented May 7, 2019

Yes, exactly. But this code is in every file. If you create, say runtime.js which can contain all shared code, rendered bundle will be much thinner :-)

@dobesv
Copy link
Contributor

dobesv commented May 7, 2019

Yeah, it's a bit unfortunate. But if that stuff isn't written inline you'll need some system to figure out where to import it from, which might complicate matters a bit.

@langpavel
Copy link
Author

langpavel commented May 8, 2019

I don't think so. Every project which use graphql-tag/loader needs graphql-tag package.
So if you introduce graphql-tag/runtime file,
you can simply do import {...} from 'graphql-tag/runtime' in generated file...

Unnecessary bits will be tree-shaked out and shared parts will be shared

It may be even more clean, transparent…

@dobesv
Copy link
Contributor

dobesv commented May 8, 2019

Yeah, maybe... I mean, that would probably work for my own project. But there are all kinds of project structures out there, I could imagine this causing issues for some people, even if I don't know specifically what issues or for who. The current approach is maximally compatible - the generated file has no external dependencies and make no assumptions about the availability of require.

That said, it wouldn't break my own project to do it this way, I'm pretty sure require('graphql-tag/loader-utils') would work in my environment. I might have to move graphql-tag from devDependencies to dependencies in my package.json.

@langpavel
Copy link
Author

Hmm, may be, but loader is webpack specific thing, isn't it?
So everyone who use loader must use webpack.
And webpack have mechanisms to emit its own runtime chunks, so it may be used like that I guess…

@lemonmade
Copy link

It's maybe not for everyone, but at Shopify we wrote our own GraphQL loader to avoid the bundle size and runtime cost of the way GraphQL tag transforms code. It relies on an additional restriction: you can only have a single query or mutation per document. With that restriction, though, we generate a completely static representation of the document, including any imported fragments. The bundle size of these documents went down by 20–30%, and they execute significantly faster since they have no runtime. You can check it out at https://github.com/Shopify/graphql-tools-web/tree/master/packages/graphql-mini-transforms#webpack.

@balazsorban44
Copy link

https://github.com/nhi/graphql-operations-string-loader Here is a loader that supports multiple operations per file, and outputs them as named export strings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants