Graphql-code-generator: bug: live editor takes too long to render

[iamclaytonray]

Describe the bug
A clear and concise description of what the bug is.
When initially loading the website, the editor component takes a couple of seconds to load in. Some people can completely miss this by navigating away from the page (ie: going to the docs) before this component even renders.

To Reproduce
Steps to reproduce the behavior:

1. Use '...' as schema
2. Use '...' as documents
3. Run the following command: gql-gen ...

Expected behavior
A clear and concise description of what you expected to happen.
<Editor /> should be rendered almost immediately to the DOM. For people with slower connections, I think it's still a good idea to throw a loading indicator into that viewport as well.

Schema/Documents
Irrelevant.

Environment:
Irrelevant.

Additional context
Along with adding a loading indicator, is it possible to add the Editor component into website/core/? This would greatly improve the perf of rendering this component as no network requests need to be made and it can just be rendered straight into the DOM.

I experimented with this already but it seems like the core/ directory is not set up to use certain features, like CSS, ESM, etc. I don't need to do a whole refactor but can I add support for CSS and anything else that comes my way that's blocking me to get a PR open for review?

Note:
This _would_ require me to touch up on the config in Webpack, which I'm more than comfortable doing. Because it's done this way, I am thinking there may be a reason that it was done this way. Are there any special considerations that I should take into account before making any drastic changes?

If allowed, maybe I could lazyload <Editor /> and wrap things in <React.Suspense /> in order to suspend the loading indicator for those on fast connections. Something like 300ms - 500ms? This would be a nice feature but I'm more concerned with the above issues. Thanks!

[dotansimha]

Hi @iamclaytonray ! Thank you for reporting it.
You are right, it takes way too long to load the live demo, and we should definitely improve it.
We can't add the website to website/core because the current implementation of the website it using docusaurus, and it only generates static HTML output, which we can't use to run the live demo (React) application.
I think the issues with the slow loading is caused by the huge bundle, and we should address this issue (it takes about 4MB because of all the codegen and plugins dependencies).

[iamclaytonray]

Could we switch to another library? react-ace is pretty lightweight and hopefully would get us at least under 1MB.

https://securingsincity.github.io/react-ace/

[dotansimha]

@iamclaytonray It's not only a matter of the editor, the whole website is static, so we have to load the live demo as iframe.
We can try react-ace instead of codemirror, but I think most of the bundle it not the editor.

[iamclaytonray]

So, for now, I've just added a loading indicator (<CircularProgress /> from Material UI) and running a setTimeout to switch this.state.isLoading to false after 1000ms. At the very least, people will know something will be there. I was able to get things down to 3MB and also using dynamic imports.

I must have read something wrong b/c I thought the generators were coming from the editor lib, which is why I made the suggestion to switch. Still going to work on debugging this + finding optimization areas. Thanks for your help so far!

[dotansimha]

Thanks @iamclaytonray !!! Can you please open a PR and make these changes in small steps? It will be easier to merge it.

[dotansimha]

Fixed in the recent refactor, we also have a package for the executor and a package for the cli. The executor is able to run without any cli deps. @ardatan also added tree shaking and bundling so it will work WAY faster when we'll release and deploy it (about 1-2 sec to load).

[dotansimha]

Fix available in 1.0.0 👍