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.

  • wthit56@lemmy.worldOPEnglish
    2·
    1 month ago

    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

    • perchance@lemmy.worldMEnglish
      1·
      1 month ago

      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.

      • wthit56@lemmy.worldOPEnglish
        1·
        1 month ago

        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?

        • perchance@lemmy.worldMEnglish
          2·
          1 month ago

          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 to window.__fooPluginFn which is the foo function, so if you’ve got fooPlugin={import:foo-plugin} then you can write fooPlugin.prop immediately and it’ll work fine.

          • wthit56@lemmy.worldOPEnglish
            1·
            1 month ago

            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?

  • BluePower@sh.itjust.worksEnglish
    1·
    1 month ago

    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.