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.

  • @wthit56OP
    link
    English
    24 months 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? @[email protected]

    • @perchanceM
      link
      English
      1
      edit-2
      4 months 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.

      • @wthit56OP
        link
        English
        14 months 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?

        • @perchanceM
          link
          English
          2
          edit-2
          4 months 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.

          • @wthit56OP
            link
            English
            14 months 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?