It creates objects for the import, but when accessing it it throws the error Cannot read properties of undefined (reading 'getSelf') from line in the getter:
let moduleRoot = window.moduleSpace[moduleName].getSelf;
So it seems like it thinks it’s there, but it hasn’t actually loaded in at all.
Short-term, a more useful error message would be useful for creators. But ideally, it would actually load in the import when createPerchanceTree is called.
Oh that’s pretty sweet! Not what I was talking about though 😅
(Edit: Ah I think I see what you mean. You’ve made it so that it’s
createPerchanceTree’s responsibility to add it to the moduleSpace. In mine I just added it from what was imported, on the import side. But I guess either way gets the job done.)I was talking specifically about calling
dynamic_import(name). It returns the imported thing, but doesn’t save it towindow.moduleSpacewith that name. Looks like it caches it for its own use, but doesn’t put it in the moduleSpace for everything else to use after it’s imported.I actually made my own recursively loading thing (not really recursive but looping through all import names it finds), and built it into my own createPerchanceTree function: https://perchance.org/advanced-createperchancetree
Has demos within that page too so you can see it working.
If you can give feedback on https://perchance.org/dynamic-import-plugin-test1 that would be great. You should be able swap out your
{import:dynamic-import-plugin}for{import:dynamic-import-plugin-test1}and if it doesn’t do something that you want it to, or if it breaks something, or whatever, let me know.Btw, I don’t think this is correct:
imported = dynamic_import(name); window.moduleSpace[name] = imported;since the dynamic import plugin returns $output of the module if it has one.And in general, making your own edits to
moduleSpaceis probably not a good idea. If there’s something like this that you want to do (i.e. “messing with internals” to some degree), then you should always make a feature request. Otherwise all your stuff could break at some point due to engine implementation-detail changes. But if something is documented in perchance.org/examples or perchance.org/advanced-tutorial then it’s safe to use.Yes, it works fine by the looks of it. 👍 I’ve integrated it into my createPerchanceTree version too.
I wasn’t sure if I was doing it right, but it did work anyway, so I left it at that. I know I’m playing with fire doing stuff like this but it’s either that or sitting on my hands doing nothing. I find it more interesting trying to do this stuff myself. And I always chat to you about it here anyway, to find out if there’s a way I’m “supposed” to do it, or if there’s just no official capability yet.
That’s how I even found out about that importer. I just needed it extended to fit my needs.
I have also read through both of those, so I’m up to speed. There’s just a lot of stuff the engine can do, just not through official means. And I like to dance on the edge 😜
I really love how you just dig in and solve the problems yourself - this is a very useful trait to have in life. So long as you let me know so I can create an “official” way I’m happy 😅 Thanks for pushing at the edges of the engine - it’s very helpful! I’m going to switch https://perchance.org/dynamic-import-plugin to use the new recursive import code now.
Great, I’ve updated my createPerchanceTree with that now 👍
It’s nice you’re cool with it. I could imagine someone else just being annoyed–this is better I think 😁
By the way, with my createPerchanceTree, I’m now setting the moduleSpace property to the equivalent of
dynamic_import().$root.getSelf, and it seems to still work. Does that look right to you?Oh I’ve put it back to using the original importer now by the way, so you can delete that test if you wish–it’s safe.