Add JS lib function call and store blocks

Efficiency does go pretty downhill when every time you need to run custom JS functions you need to generate new ones. You could store them in variables (lists) or the global space but I believe this is a better option. Allow people to have some sort of "auto execute" when importing libraries or making one (or just do it in an import block, requiring that it is ran first). This will be used to create the functions and store them by name in some library namespace. Then allow those functions to be called both in JS (libname.func...) and from a block without needing to create new functions each time. This is especially since even if the functions were stored in the global namespace, another JS function would need to be used to perform a call. This is also a better alternative to polluting sprite variable namespaces

That's an interesting idea. But what I want to do, a more general solution, is have a block that defines a block:

or something like that. Then the script input could be a JS Function or anything else.

But I see your point that if it's a JS Function it should be callable from JS without going through the JS Function block each time. So maybe a DEFINE JS block that's a cross between my DEFINE and the existing JS Function.

We're reluctant to do auto execute because it means you're running someone else's JS code without a chance to examine it. Maybe as a special case for official libraries.

As for auto-exec, you can just prompt the user the when the library is imported.
Also yes but what I had in mind was more like this:

|new library [name]|

|define [funcname] for [libraryname] as [jsfunction]|

(call [funcname] from [libraryname] [inputs]...>)
|run [funcname] from [libraryname] [inputs]...>|

The library could potentially be inspected from the last call as well (being replaced if using new library with the same name)

I see. The idea of using the library name at runtime is orthogonal to everything else; we could do it for Snap! procedures too. But we haven't felt the need for a module system so far; could you say more about why that part is important?

Its mostly for a few reasons:

  1. Efficiency is improved by providing a way to store constant functions and call them instead of making new ones each time
  2. Readability is improved as all the inlined functions would be replaced by calls within the block definitions
  3. People can read the import block to discover comments about function code and other information.
  4. Ability use the paired function from a block or from JS itself.
  5. Functions will associate to libraries and have less chance of collisions than if set up the aforementioned ways. They will also be "named," allowing for potential drop-down menus that might show the comment when hovering and allow for easy access (could even select based on the library name). The drop-down could select both the library name and function name as well when empty.
  6. Other libraries may be imported (when required and imported alongside the library) and it should not cause issues with loading the libraries.

Okay, your #5 anwers the question. Sigh. We've really been resisting turning Snap! into a heavy-duty industrial language. Dan Garcia wants us to enforce type declarations; you want modules; pretty soon someone will ask for interface templates. I see why an industrial language such as Java needs all those things, but we cherish the idea that an 8-year-old can come to Snap! and start hacking away without the weight of notation to cope with. So the question is how to give you grownups what you want without it getting in kids' faces. I'm proud of how we designed lambda for Snap!, but it took us three tries to get it right.

Anyway, we'll put this on the discussion list, but I'd be happier if you wrote a library we could publish. That's one way to keep industrial-strength features out of kids' faces.

Yea I understand that this isnt something like Roblox where its target development audience is more for teenagers, but this would just allow it to be more useful and run better. I was using this in a few of my projects which are still around learning how to code instead of using Snap! for professional purposes. A good example is a Discord library I was working on for a while where you could interact with webhooks and bots in simple ways.

But the main issues are with clutter and performance problems. Things that these new blocks would alleviate (i can show you the crazy source for some of these blocks). They should not be difficult for children to understand as they would not need to see the inner workings unless they want to know how things work. The library stuff should be non-obtrusive, used only within the custom blocks provided by the library.

On a side note, it would be great if the custom blocks could be categorized in some way either by library or by editing its properties so that they are more well sorted and displayed.

Oh, I see! The library would "publish" blocks that don't have the module name attached. That could work.

By the way, our preference is to construct data structures functionally:

And even if they did see the block source, it will be a bunch of simple function calls with proper naming. If they want to see the library function source they can go and look it up.
The message object internally is a JS dictionary that gets a lot of casting, conversion, and modification done but it would be easier to explain if the functions were just named. Especially since theres some blocks i make only for library purposes which clutter the environment so i don't have to repeat myself in code.
Also, sure, I guess, there could be ways to define blocks using JS sources directly but I believe that it would be more complicated and still create a bunch of blocks that would inevitably be imported. These "libraries" or "modules" would reduce the clutter greatly because they won't create a huge list of blocks. They would just be a part of the library namespace. Its the difference between making a bunch of functions within a JS file and then trying to write code with all those functions in the way VS importing a module with the functions only within the module and they can be looked up when needed.

A lot of my blocks use other blocks ive created like helpers, as I've stated before, so there are dozens of blocks that the developer will never have to use there. There also is the readability which is hard to describe without sending source (I am on mobile and Snap! has really really really bad mobile support so I cant open it).
Although, JS coded blocks would still be a nice feature. I just believe that this library setup will be more useful, especially for "hiding" implementation in a way where its easily accessible but not obtrusive.

Okay, I get it. I can't promise that we'll do anything about it any time soon--we have plenty of missing features already on the list.

Ok. If I had any time aside from other personal projects I would probably just try and make the block myself as a pull request but it would take too long to figure out.