Adding a loading animation when the playground while generating output
Gmin2 opened this issue · comments
When you change the input, open the studio or change the settings, the studio need to ask the backend to re-generate the output, and there can be a significant delay here depending on input and latency to the backend server. Therefore I suggest we add a loading screen to the output view that showcases that it is currently in the process of being generated.
AsyncAPI.Studio.-.Google.Chrome.2024-01-21.18-33-00.mp4
as you can see in the video when we change the document it takes some time to validate it and it shows Empty or invalid document. Please fix errors/define AsyncAPI document. instead of this if we can add a loading animation.
@Min2who thanks for reporting this issue ? an example of what you are trying to do with reproduced steps.
A screenshot/recording can help as well.
Thanks
@Min2who thanks for reporting this issue ? an example of what you are trying to do with reproduced steps. A screenshot/recording can help as well. Thanks
Done @Amzani
I think there are basically 2 issues:
- Generating the output takes a significant time. For me it's ~2-3 seconds even with the simplest document. Having this delay after each few character change in the editor is pretty inconvenient.
- While the output is getting generated, the main thread is occupied, thus the complete page is unresponsive for that time period. I believe this is what this issue refers to.
I'm not familiar with the studio architecture, but as I see, when changes are made in the editor, the FE sends requests to the BE only the first time (to get .js chunks). From there on, no further requests are made when the document gets changed in the editor. This makes me believe that the document generation happens on the FE side only.
In my opinion, if possible, it would be worth to focus on the first point as a quick output would make the second point pretty much obsolete.
@Amzani what do you think? If further info or creating separate issue would be desired, let me know.
@Amzani I mostly have sw testing experience, besides that a little js/ts and no react, so I believe I couldn't handle the implementation, but if I can be of any help, let me know.
Some further observations that may help:
Validating/parsing the "Streetlights MQTT API" example takes approximately such time for me with the following tools:
- Studio: 2000-3000 ms (based on Chrome devtools performance capture)
- @asyncapi/parser's Parser.parse(): 620-650 ms (measured with console.time() in Node.js)
- Spectral VS code extension: 300 ms (measured with stopwatch so not really precise)
As far as I understand, Studio uses @asyncapi/parser, which uses Spectral (@stoplight/spectral-core), so I believe there's room for improvement some way.
Hey @Amzani is this issue still open for PR's?
This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience ❤️