Considerations on having more that one document in workspace in react/wrapper usecase

[cdietrich]

Considerations on having more that one document in workspace in react/wrapper usecase

We have the following usecase:

• we want to user give the opportunity to edit one file in the webbrowser (react app)
• in this files elements from other files should be referrable

Right now we do the following

• we have customized main-brower to receive a (initial) message with that other files contents and then construct the language worker with a special Workspace Manager that know the files as builtin resources

This works fine until we want to exchange the to be edited file along with its other files in react.

If the component is not remounted, then the componentDidUpdate call wont reinit monaco as before and after we just have a worker
thus we cannot plugin a new worker

we currently circumvent this problem by passing a key to the component to force remount

i am thinking about what could be done to make this nicer or more generic

• instead of using workspaceMgr and builtin files we could use lsp didOpen calls to open multiple files. if the protocol works fine they all should end up in the same ws and visibile to each other (did not test that yet), but this also would require a hook in the component or a prop to pass multiple resources

• we at least could make the current approach more robust by adding a prop to force remount on componentDidUpdate

do you have more ideas or hints? Thanks

[kaisalmen]

@cdietrich sorry, I forgot to answer this. Didn't do it immediately and zoom a week passed by.

First, I would look at the problem without considering react and think about how it could be realized directly.

You could create a RegisteredFileSystemProvider and register all your files to it (there is currently no examlple in this repo, but here: https://github.com/TypeFox/monaco-languageclient/blob/main/packages/examples/src/python/client/main.ts). Then you can use the uris to create the models for the editor. When you update the model in the editor, then the language server will get notified automatically. You require language client logic to identify links between files.

A good source of inspiration what actually can be done with the underlying monaco-vscode-api you get here: https://codingame.github.io/monaco-vscode-api/
and of course from the source here: https://github.com/CodinGame/monaco-vscode-api/tree/main/demo

[cdietrich]

hmmm i still cant wiggle my head around this.

isnt the RegisteredFileSystemProvider a pure client thing?

Then you can use the uris to create the models for the editor. When you update the model in the editor

does this mean i have to client.didOpen somehow manually? calling updateModelseems to swich the model displayed in the editor

i also wonder why the onLoad callback does not have a callback paramter to e.g. the wrapper or the component itself

[cdietrich]

in my current approach the didOpen does seem to work.
but with the wired non recycling of monaco and the wired recycling of the worker it feels a bit overshoot.
also the component does not really be subclassable in a nice way.

https://github.com/cdietrich/my-monaco-editor-react-example/tree/cd_referencingOtherFiles