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.”
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 ;P