Seems like plugins almost always have some sort of setup to go through when they’re first used. Really, they’d want to just run that code when first imported. But presumably there is no way creators can do that, currently. As it’s such a common use-case, having something like this built-in for plugins would be useful, I think.
Also, would be useful for things like having $output be a function. But give it properties also. Unsure how to do that currently. …Though, also not sure if this $onload() thing would let that work anyway.
Any advice on doing this? @perchance@lemmy.world
having $output be a function. But give it properties also
It’s hacky, but I do that like this:
$output = [getPlugin()] getPlugin() => if(!window.__fooPluginFn) { function foo(a, b, c) { // the actual plugin code } foo.prop = "blah"; foo.anotherProp = 123; window.__fooPluginFn = foo; } return window.__fooPluginFn;
I have thought about something like
$onLoad
before, but there were some complications. Currently the lists panel is purely “declarative” (loosely speaking, in the sense that no state is altered during parsing/init) and all actual execution is done via calls from the HTML panel. It’s definitely possible to have something like$onLoad
but it does lead to a few extra “if/thens” that devs need to keep in their mind when importing something, and I’d need to change some ~deep-ish engine code. When I’ve had this need in the past I also noticed that I sometimes wanted it to only run if it was a direct import - i.e. not an import of an import. So there are a few DX questions there too. For now I think this one is further down the todo/to-think-about list, since it’s pretty easy to just add[yourPlugin({init:true})]
to the top of the HTML panel.I see. So is that only run once, to store it in the local list-variable by the user? That’s an interesting way to do it. And lets us add properties… but that would only work after it’s accessed? Or could the user do [plugin.prop] and it would work as the first code block?
So is that only run once
Ah, no, good catch - that would have re-run every time. I’ve updated the code above to fix that.
could the user do [plugin.prop]
Yep,
$output
will resolve towindow.__fooPluginFn
which is thefoo
function, so if you’ve gotfooPlugin={import:foo-plugin}
then you can writefooPlugin.prop
immediately and it’ll work fine.Cool 👍
Basically, an
$onload
function to be called like that automatically would be all it takes, I think. I don’t think I’ve seen the actual importing code, but presumably it injects stuff into the top-level page or something. At which point it could call the onload maybe?
A simple, practical approach (for now) would be to put the function inside the
$output()
like this:$output() => if (!window.__onloadExecuted) { onload(); window.__onloadExecuted = true; } // ... // The homemade onload function onload() => // ...
However, it only works when at least one instance of the plugin is being executed in the generator code.
Yes, that’s exactly what I do–and exactly why I’m making this request.