Skip to content

Conversation

@sourishkrout
Copy link
Contributor

@sourishkrout sourishkrout commented Dec 21, 2025

Changes necessary to namespace contexts if not backed by Runme Runner.

Signed-off-by: Sebastian (Tiedtke) Huckleberry <sebastiantiedtke@gmail.com>
Signed-off-by: Sebastian (Tiedtke) Huckleberry <sebastiantiedtke@gmail.com>
@sourishkrout sourishkrout changed the base branch from main to seb/safe-custom-elements December 21, 2025 20:30
Signed-off-by: Sebastian (Tiedtke) Huckleberry <sebastiantiedtke@gmail.com>
@sourishkrout sourishkrout changed the base branch from seb/safe-custom-elements to main December 21, 2025 20:39
@jlewi
Copy link
Collaborator

jlewi commented Dec 22, 2025

I tried this and it works but I think it might be brittle and cause problems down the line.
As I mentioned in #28 (comment)
It looks like this doesn't define renderers to be a peer dependency. So I think we wind up with react-console having its own copy and the app with a different copy. In particular when I look at my node_modules I see

ls -la packages/react-components/node_modules/@runmedev 
total 0
drwxr-xr-x@  4 jlewi  staff  128 Dec 21 15:32 .
drwxr-xr-x@ 13 jlewi  staff  416 Dec 21 15:32 ..
lrwxr-xr-x@  1 jlewi  staff   22 Dec 21 15:32 react-console -> ../../../react-console
lrwxr-xr-x@  1 jlewi  staff   18 Dec 21 15:32 renderers -> ../../../renderers

ls -la packages/react-console/node_modules/@runmedev 
total 0
drwxr-xr-x@  3 jlewi  staff   96 Dec 21 15:32 .
drwxr-xr-x@ 10 jlewi  staff  320 Dec 21 15:32 ..
lrwxr-xr-x@  1 jlewi  staff   18 Dec 21 15:32 renderers -> ../../../renderers

Since we are relying on the module variable "context" map I think we will wind up with problems where different code is referring to different things. I assume the DOM custom element will use which ever instance actually succeeded in registering the element. However, code that calls getContext/setContext will depend on which module its importing.

Why Do We Need RenderContext

Why do we need RenderContext if the communication with the Runner is actually handled by "streams.ts"? IUC RenderContext is needed when running in VSCode to send messages from the main application to the render. In particular it looks like if the window in which the renderer gets resized the application sends a message to the renderer with the new size so it can be taken into account. In our case the window size gets sent via RPC to the Runner; presumably so the runner could adjust output size based on the window size.

Supporting vscode & non-vscode

it looks like VSCode needs to use RenderContext to pass along information to the renderer's webview. I believe this happens when the extension gets activated here by calling setContext.

So it makes sense that in vscode we are relying on a module level variable to store "App State" that has been passed along.

Is using a module level variable the right pattern in non-vscode settings?

Could we

  • Allow the RenderContext to be set on each ConsoleView/RunmeConsole
  • So it is the responsibility of whoever creates ConsoleView to use a shared or non-shared context

If IUC we control creation of the Console elements in renderOutputItem. So could we just set the attribute there to the shared RenderContext in the vscode case?

@jlewi
Copy link
Collaborator

jlewi commented Dec 22, 2025

My latest attempt is #28

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

Successfully merging this pull request may close these issues.

3 participants