Clarification around registerJSModule

[WebReflection]

There's not much to read in the official docs so I've thought that maybe it's worth asking in here before going mental about implementing the same in other runtimes and/or in PyScript ... we've noticed that in polyscript when we register polyscript as a module and it has its own field attached, we can then use that field to import stuff from it:

from polyscript.field import whatever

This works "by surprise" because in Python one cannot use dictionaries to import stuff from them but in this case polyscript is a dictionary and the only special thing about that field is that it's a Proxy that indeed resolves stuff lazily.

Are we correct in assuming that registered JS modules in Pyodide act as if these were containing submodules per each filed or ... in case this is not an undesired bug, what is the thinking behind this "feature", if meant?

Thanks in advance for any sort of clarification around this topic!

/cc @hoodmane

[hoodmane]

Yes this is the intended behavior. We should update the docs to be more clear about it.

I think the perspective we took was as follows:

1. It's useful to be able to have submodules but not clear how to decide which things should be treated like submodules vs like attributes
2. It's convenient to be able to do e.g. from js.document import addEventListener but there's no way to know ahead of time that document should be treated as a submodule
3. Different stuff is in node vs the various web global scopes vs other runtimes, how would we pick which ones are useful to treat as submodules?
4. I'm not aware of any downside to allowing this.

So I don't expect we'll ever want to change this. It's a bit weird but there's no other approach which is better.

[WebReflection]

uhm ... in case of from js.document import addEventListener is that addEventListener automatically bound to js.document ???

about the rest, I understand the current design and indeed it is desired but to normalize it for our current polyscript.js_modules use case I've decided to register both polyscript and, explicitly, also polyscript.js_modules as modules.

This solves the issue with MicroPython so that now we can:

from polyscript import js_modules
js_modules.thing.stuff()

# as well as ...
from polyscript.js_modules import thing
thing.stuff()

As I've tested both approaches and there's no apparent caveat or side-effect and it works well with other interpreters, I think the gotcha/issue/question is resolved.

Having attributes automatically resolved might be tricky in other runtimes so it would be good to have this detail in docs.

Last, but not least, thank you for your time and Merry Xmas + Happy New Year 👋

[hoodmane]

is that addEventListener automatically bound to js.document ???

Yup. If a is a Js proxy and we access a.b then we do Reflect.get(a, "b") and if the typeof that is "function" we store a as the thisArg for when we apply the function. (Note that we don't call bind because that creates a new object.)

Merry Xmas + Happy New Year

To you and your family as well!

[hoodmane]

I've decided to register both polyscript and, explicitly, also polyscript.js_modules as modules

Do you mean by directly inserting them into sys.modules? I suspect this is a good thing to do if you don't want this behavior since it's probably the main difference between calling registerJsModule and inserting into sys.modules directly. It would be a good idea for us to say so in the docs.

[WebReflection]

I've used registerJsModule('polyscript', polyscript) and, before that, registerJsModule('polyscript.js_modules', polyscript.js_modules), which plays well in both Pyodide and MicroPython and apparently Wasmoon too so ... we should be good.

[WebReflection]

btw, in PyScript I've used sys.modules["pyscript.js_modules"] = polyscript.js_modules and indeed it works like a charm 🥳