Currently, as far as I’ve figured out, in the HTML we can have {import:...} and it will be accessed. So we can use that to actually run code immediately. Using it this way means it won’t be included in the lists for when it’s imported into other generators, but we can still use it in that specific page.
But we can’t use {import:...}.property or {import:...}(args).
In the lists, we can have imported={import:...} and it will load in but not be accessed. To trigger the access, we have to use [imported] someplace that is accessed–in the HTML, or perhaps depending on the situation, something like that. Which is counter-intuitive, as the code we’re writing to import it in the first place is literally an assignment (by how it looks at least).
But if it’s in the list at all, it’s now part of the dependencies included when importing it into another generator. Which, if we’re only importing it into the list to be able to call in the HTML, is not explicitly intended by the creator. As this kind of assignment doesn’t actually access the imported thing, at least it’s not going to actively do anything. But ideally it just would not be required.
On the other hand, it would be useful to be able to simply say {import:...} and have it import, even without a name to store it under. It’s clear what the creator wants, from that code. And it works exactly as expected in the HTML panel. On the other-other hand there’s no way to call an imported function or access an imported property from just the HTML so it needs to be part of the dependencies of the plugin itself.
If my plugins were actually used by anyone (LOL) this would have been a pretty big issue when I recently made a typo (and got stuck being unable to fix it for a time) in a not-required-at-all import that had to be there purely for the plugin’s page to use.
If I could’ve just imported it and used it all within the HTML panel, it wouldn’t have been so urgent, because the error would not have affected any users of the plugin–only my own page presenting it.
The main thing here is, they work differently–seemingly (from the outside from an average creator’s point of view) for no real reason. So learning how import works correctly is made more difficult. And learning how it works just for lists or just for HTML is easy… but of course trying to use that knowledge in the other panel leads to confusion and frustration because actually there are different unforeseeable rules there.
Could well be that for backwards-compatibility some of this could not be changed. But perhaps things could be expanded to allow for more features to be cross-compatible, and more expected/very common features to “just work.”
Is this tl;dr correct? You want:
{import:...}.propertyor{import:...}(args)in the HTML panelCombined, they would allow for e.g. importing perchance.org/comments-plugin into perchance.org/my-cool-plugin without causing every generator that imports my-cool-plugin to also have to uselessly import the comments plugin code.
Is there anything I missed there? If not, I think the best approach to solve both #1 and #2 is to use the perchance.org/dynamic-import-plugin You still have to import that plugin, of course, but it’s very light-weight, so it’s fine if importers get that as an additional dependency. Example:
https://perchance.org/import-only-in-html-panel-no-dependency-example#edit
This is really only possible (in the general case) thanks to your prodding me on getting recursive imports working on perchance.org/dynamic-import-plugin - so thanks!
That said, I think #2 should be possible without too much trouble. #1 is a bit harder because it requires some new syntax, but still viable.
What I’m doing for now is, my private plugin just sticks the function on the window. So then I don’t need a handle to get it by, so I don’t need it to be in the lists.
In the HTML I have:
Another method I found doesn’t need to add stuff to window, but is super jank to write. The plugin would have a normal
$output()=>...and in my HTML I’d have:One thing I did try is, the imported $output has a toString which gives some HTML like
img src=x onerror=alert. In the HTML I’d have<{import:...}("blah")>and it would actually work! Just not with something more useful where the onerror gets the reference to the $output. Gives strange perchance errors that make no sense (perhaps references to internal variable names), for some reason I can’t trigger debugger, or breakpoints (though sometimes I can, sometimes I can’t)… it’s just a nightmare getting anywhere with it unfortunately. Thought it was a cool (and also hyper-jank) idea though ;PYes that’s about it. I don’t know what syntax it should actually have, but that’s what I’d want to do with it anyhow. Maybe even {import:…} works within [code blocks] or something crazy? Like, rewritten to call some import function?
Come to think of it… one way of doing this might be to just have
import()as a built-in function. So you can always easily import something no matter where you are, and use it immediately. Then there’s not even an extra dependency. Though it’s built into the system itself, but that’s probably fine anyway. (Perhaps you’d avoid actually reusing the keywordimport, to avoid people thinking it will work exactly the same as the keyword normally does. But you get the idea.)🤘
Another (perhaps simpler) thought occurred to me regarding syntax.
{name=import:generator}would be just fine. Very easy to parse, and hopefully easy to add to whatever regex you’ve got going on for it currently. Just setswindow["name"] = imported.$outputor whatever.