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
Improve lazy-loading of Monaco editor #532
Conversation
d743971
to
54a4494
Compare
- Use more dynamic imports for Monaco editor -- Expose dynamically imported -- Use type imports where possible to avoid full resolution - Expose as much options for outside configuration as possible - Avoid unnecessary boolean return type - Avoid loading Monaco editor only for key codes - Align react-query versions with process-editor-client Co-authored-by: Olaf Lessenich <olessenich@eclipsesource.com>
54a4494
to
96ee198
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. But maybe a quick explanation would be great.
More and more I think we need a separate package with all this monaco stuff in it:
- Setup monaco environment
- Setup lsp connection
- Provide react monaco component
- ...
@@ -1,14 +1,14 @@ | |||
import { createWebSocketConnection, type Connection } from '@axonivy/jsonrpc'; | |||
|
|||
export namespace IvyScriptLanguage { | |||
export async function startWebSocketClient(url: string, isMonacoReady: Promise<boolean>): Promise<any> { | |||
export async function startWebSocketClient(url: string, isMonacoReady: Promise<any>): Promise<any> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not Promise?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not Promise?
I'm not sure I fully understand but the return type that we typically use here is of monacoEditorReact.Monaco
but since we are not actually awaiting the result in this function, I typed it any (instead of void
or boolean
previously) mainly to ease changes and avoid conversions like MonacoEditorUtil.getInstance().then(() => {})
but also highlight the fact that we do not care about the return type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry not everything was posted...
I wanted to write Why not Promise<void>
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does my post above answer the question? Basically we want to avoid unnecessary conversions.
I agree that in the long run that might make things easier. However, some things are little bit more intertwined as they manipulate the global I'm happy to provide additional explanation: Documentation, code comments, etc.? I tried to separate out things into dedicated functions as much as possible and add comments here and there. But the basic steps are: initialize the monaco API, configure the language client ("VS Code API") connection with the monaco API, add worker creation to the As for the lazy loading: The goal is to async all the heavy imports into promises so they are not loaded when the script is parsed initially but only once we actually trigger the loading function. |
Yes, I think, I understood the changes. Yes, can definitely be in a later PR. |
I will merge this now, ok? @martin-fleck-at |
@ivy-lli Yes, thank you! |
@ivy-lli Do you know how long it usually takes for the new version to be available so it can be consumed in the process editor? |
-- Expose dynamically imported
-- Use type imports where possible to avoid full resolution