Thanks,
getting
streamlit.components.v1, to work will unlock many of the potential benefits
streamlit.components.v1 is already supported (with some exceptions).
Supporting custom components is meaning it.
The technique introduced in that topic is currently not possible on stlite, but it’s not due to the lack of streamlit.components.v1, but of the way to mount multiple files.
If you want to do something like that, please wait for Multiple scripts · Issue #4 · whitphx/stlite · GitHub.
But I have a feeling that accessing the underlying DOM and communicating objects with JS is a more native approach here. No?
No, for this case [1].
As I have written, Pyodide is running on a web worker, so it’s not possible anyway.
And even if possible, Streamlit of course does not have such Pyodide-native APIs, so we should not use such APIs on stlite apps too.
stlite is a “transparent” layer that bridges Streamlit to Wasm/Pyodide, so I don’t have a plan to provide its original API including the way to manipulate DOM that will probably conflict or break the original Streamlit design.
For example, especially about this topic, directly manipulating DOM breaks the Streamlit frontend because it is well-managed by its React app and must not be controlled from outside.
As Streamlit already provides a way for devs to do it safely, which is called as “custom components”, where the third-party code is sandboxed in an iframe and guaranteed not to break the other parts of the frontend, so we should follow that way.
Shuny by the way has apparently this tags UI elements that can run custom JS code (see their Wordle example). So it might be technically doable.
From my understanding, Shiny’s ability to inject JS code into the frontend is not such a “native” API.
Shiny being possible to inject frontend code is at the same level to Streamlit being able to load any code into the frontend as a custom component.
Of course the Python versions of both do not have the “native” way to control the frontend JS from the Python code, and both have some APIs to “bridge” them which are tags$script for Shiny and custom components for Streamlit.
The situation does not change even when they are ported to Pyodide environment; stlite for Streamlit and Shinylive for Shiny.
Both stlite and Shinylive simply run Streamlit or Shiny on the web worker with no (or little) modifications and try to keep the original APIs available. Then, they still do not provide the Pyodide-native way to control DOM from Python.
Maybe, PyScript have a similar philosophy. From my understanding, PyScript is a wrapper of the Pyodide DOM APIs (with some utils). ↩︎